BKeeney Briefs

Nearly every project I’ve ever worked on (even in my electrical engineering days) has had lengthy requirement documents.  Whether I did it, the team did it, or the customer did it, the requirements documentation was generally the bible of what the project was going to do.  Changes to the bible caused change orders and resulted in large sums of money being thrown away.  In one rather large project I spent a full year on the requirements and documentation before I did any massive coding.

Agile is definitely different.  Our 5 person scrum team is working on 3 week iterations and we just finished iteration 0 meaning that all we did was figure out what to do in the next couple of iterations.  So we’ve defined what our epochs, stories and some of the tasks so far.  We’ve been using an agile tool from Rally Software that makes the process easier to manage.  Each iteration is planned out so everyone isn’t burned out at the end which is kind of nice (though I know we’ll have a few long days here and there).  At the end of the iteration we have show and tell with the product so the client can give feedback and review how well the iteration went.

The new iteration starts out with a planning session to identify all the stories and tasks your going to work on.  Then you start working on it.  So what this means for us developers is that we might be writing throw-away code and I’ve never done that before.  I’ve always planned on the code being their for all time.  This will take some getting used to.  It means that we only ‘know’ about the stuff that’s coming up in the next iteration or two which means that assumptions we make right now might not necessarily be the case in 6 weeks.

Of course, the whole point of the exercise is to get something to the client quickly so they can a) save money and b) have exactly what they want.  The traditional water fall method takes a long time and often times the results are not what the client wanted at all.  Living in Kansas City where Sprint is a major employer, it’s hard not to know someone who hasn’t been on a water fall project that took 2 years and was cancelled at the last minute because it didn’t meet the project of objectives (but still met all the requirements!).

That’s all for now.  Anyone else done an agile project before?  What was the hardest thing for you to get used to?  The benefits?  Drawbacks?

In December 2007 I wrote in my wish list that I wanted them to start using a modern bug tracking system.   Let’s be honest, the old one sucked so I wish everyone would stop moaning that they liked it.  We put up with it, but once you use a real bug tracking system instead of the one they wrote and half implemented, you’ll realize how bad it was.

With that said, those making the decision to kill access to the old were smoking something.  Not everyone is using the most modern version of REALbasic.  Heck, there are more than a few developers still using RB 5.5 so removing access to it was a very bad decision.  Okay, so now they’ve brought it back as read only.  That should have been the plan all along.

FogBugz may be awesome.  I sure can’t tell from RS’ comments.  Can’t search for bug reports and workarounds?  I can’t believe that Joel Spolsky would implement a bug tracking system that you couldn’t search.  Come on, the guy wrote a good portion of Microsoft Excel.  He knows his stuff.  He’s good.  And his bug reporting system doesn’t have public vs private bug reports?  I can do that in my free Mantis bug tracker.

So yeah, RS dropped the ball on this one big time.  So instead of the sh**storm they’re dealing with now, this simple forum post (or one like it) would have prevented some of the outrage:

To All REALbasic Developers:

It has become increasingly obvious over the past several years that the Feedback System (i.e. the Feature Request/Bug Submittal System) for REALbasic and REAL SQL Server is not adequate for our internal needs, nor the needs of our customers.  The Feedback System does not have many of the modern features that we, and our customers need and are now demanding.

After a lengthy evaluation process, we have chosen to use FogBugz, an industry leading bug tracking and reporting system.  We feel that using FogBugz will allow us to meet the increasing demands of not only our customers but our internal developers as well.  Starting April 22, 2008, FogBugz will be the only method of submitting bugs and feature requests to Real Software for all of our products.

This change is not without some drawbacks.  Since the feedback system contains many years of bugs that are no longer relevant we have decided that none of the existing feedback system reports will be migrated to FogBugz.  There is so much old data, however, that we felt that it would cause more problems than it solved.

In addition, the current FogBugz implementation does not allow a public search of bugs, nor is there a way to add yourself to an existing feature request or bug and therefore we will have to write some additional tools and reporting mechanisms into the system.  We understand that these are must have features for many of our users so please be  assured that we are trying to implement these features with the help of the FogBugz developers as quickly as possible.  Unfortunately, we do not currently have a timeframe for these to be added back in.

In the meantime, the old Feedback System will remain in place in read-only mode so REALbasic users using older versions may still search and view existing feedback reports.

We understand that this will place hardship on some of you that depend upon existing functionality of the feedback system and we apologize.  If you have any questions or concerns, I will try to answer any and all questions in the forums.  Thank you for the patience and understanding.

Sincerely,

Someone Thinking Ahead

Real Software, we (us developers in the real world) depend upon you to make tough decisions on our behalf in order to make your products better.  However, you still have to keep in mind that we’re developers too and we have to make tough decisions for our products as well.  This week’s situation has the appearance that you are out of control or, even worse, aren’t fully thinking through the implications of your decisions and how they affect the user base.

As a REALbasic developer I’ve have to fight the name.  Basic is well, basic.  Simple.  It can’t get any simpler.  It’s a development language that’s been scorned by developers using ‘real languages’ for years.  Mention basic to a c++, Java or .NET developer and you’ll probably note the sneer on their face.  I’ve heard these folks described as language purists.  It doesn’t matter what language their using because whatever it is is better than any basic language.

Think about the hot languages such as  Java, PHP, .NET, Cocoa and Ruby On Rails.  Each describes their language in an abstract way.  Well, you could argue that, with the exception of Java, none of examples are really a language but a framework that the development environments tie into.  I think these are tiny but significant mindset differences.

Add ‘REAL’ in front of basic and a lot of people get this mental image of QBasic and immediately pooh-pooh it.  So if there’s a ‘real’ basic then where is the ‘unreal’ basic?  Silly, I know, but the two words together just bring a ‘simple’ mental image and from my perspective, simple doesn’t sell well into a corporate environment.

So now let’s add into the mix of negativity all of the really, really bad applications that people have written in Visual Basic, and yes, REALbasic over the years.  Both development environments let an average person do some really silly things from a development standpoint.  It let’s non-programmers create relatively complex applications without having to worry about memory allocation and the like.  Let’s face it, there are probably hundreds of thousands of old Visual Basic 6 applications still being used in corporate environments so VB is, arguably, the most widely used development environment in the world.  Bad programmers are bad programmers in any language it’s just that VB and RB let you get away with some bad things simply because of their easy-to-use nature.

REALbasic is thankfully much more than that.  It’s a full object oriented language that compiles into native executables for Mac, Windows and Linux.  It’s extensible by using plugins (written in C) and by using OS dependent declares.  It’s fully Unicode aware and it works with a wide variety of open source and commercial databases.  Real SQL Server is a nice, very inexpensive database server that can be used by anyone and not just DBA types.

The REALbasic IDE is not just about the language.  It integrates the user interface with the code and even let’s you edit database tables and data.  It lets you easily edit toolbars, container controls, windows and even let you do this in multiple languages.  Heck, you can even develop and debug on one platform while the application is running in an entirely separate environment!

So what’s not to like about REALbasic and Real Software?  The name ‘REALbasic’.

If I could change it, I’d change it to REAL Studio or something completely different.  I think a change has some advantages.  One, it disassociates itself from ‘basic’ even though we all know that it’s a basic language.  Two, it tells potential users that it’s more than just a language.  Three, from a selling it into a corporate environment standpoint, anything that doesn’t have ‘basic’ in the name is one more thing I don’t have to ‘educate’ the client about.

Now the drawback to changing from REALbasic to anything else is huge.  You’re essentially rebranding an existing product and that is never an easy thing to do.  It will hurt until the new name sticks and pain for a business usually means a hit on sales and I’m not sure that RS is ready to survive a six month (or longer) drop in sales until the new name is established.  There is also the risk that the public will absolutely hate the new name or perhaps even worse, find it funny or offensive.

So what are you thoughts on renaming REALbasic?  Good idea or bad?  Why?  What would you rename it as?

It’s been quite a project.  I was first brought in to write reports using Crystal Reports and do miscellaneous things in their VB6 project.  Back then, we were still waiting on a lot of the things to get coded so they had me work on preferences.  Then user security.  Then MapPoint integration.  Then flat file imports.  Then payroll.  Wait.  Did I say payroll?  Did I know anything about payroll?  Nope.  Not a thing.  I now know way more than I’d like to about payroll in the United States.

I finished coding payroll and we were STILL waiting on our resident ‘genius’ (an MBA with Microsoft certifications up the ying yang) who still didn’t have the general journal done after months worth of promising it was ‘just about done.’  I was tasked with getting budgets up and running and account balances were taking forever (15+ minutes to get 300 account balances).  Because our self imposed release was quickly approaching we couldn’t wait anymore so I created the General Journal tables and code to deal with populating it based on all our various accounting transactions.  Now, 300 account balances take just a fraction of a second (as it should).

We released it to the public and we won some awards.  And then we discovered why using Microsoft Access/Jet as an accounting database was a horrible idea.  Database corruptions were commonplace because client networks were so bad that Jet couldn’t fix itself.  We start stashing copies of the database ‘just because’ and gave warnings that users should compact and repair their database on a regular basis.  It was at that point the owner allowed me to look into using SQL Server instead of Access.  Did I know anything about SQL Server and VB6?  Barely.

Going from almost zero knowledge, we got SQL Server up and running in about six months (while still releasing new features).  Since we had long since figured out how to minimize corrupted databases (but never completely eliminated the problem) the client naturally decided that SQL Server wasn’t important to his long term growth.  So SQL Server was (mostly) abandoned.

Along the way we refactored payroll to speed it up by a factor of 10.  We rewrote sales tax to accommodate the crazy schemes the politicians come up with to get money.  We were able to convert QuickBooks into our package with roughly 99% historical accuracy.  We investigated many things to see how long and how hard it would be to implement such as report designers and integrated charting and even releasing to foreign countries.  We rewrote large sections of code and changed out controls in Visual Basic that were better than the existing controls.

I mentioned that we mostly abandoned SQL Server.  That’s not really true.  The one full-time developer on their staff and I kept developing as if we were using Access and SQL Server which was a great idea because eventually they sold copies of the product to some very big companies.  And naturally Access/Jet choked and died a miserable death in those high data environments.  Our forethought saved our collective bacon when we were able to switch them over to SQL Server with minimal effort.  Jet errors vanished nearly overnight.

As a company, my client won some local awards as a great place to work in the Kansas City metro area.  They treated me as an employee (for better and worse) which meant that I was invited to their Christmas parties and got dragged into profit sharing meetings.  I knew the employees as well as I’ve known anyone I’ve ever worked with.

But as with all projects, this one is now mature and stable.  Sure, we have a huge laundry list of things we’d like to change, but we’re no longer in that startup mode where every day is about coding something new or where every day is an emergency because we (or a customer) found an issue that has to be changed RIGHT NOW.  I feel as if the really exciting part of the project is over.

So when an opportunity came along to work on an even bigger project for a very large company I couldn’t pass it down.  So starting Monday, I start working on a big project for a Fortune 100 using agile development methodology.  It’s a big deal and it has some risk but the potential rewards are huge.  I get to learn about being part of ‘scrum’ and to be part of a team where we have code reviews and formalized coding standards.  These are, frankly, something I’ve wanted to implement for a long time.

Doing a quick check on Friday revealed that the accounting project has around 975,000 lines of code in 700 project items with 200 reports.  How many of those reports did I create?  Maybe 10.  How’s that as a switch-a-roo from when I started?  As I left the building on Friday I told the client (really my friend at this point) that I appreciated him letting me play in his sandbox for five and half years and that it’s not really goodbye.  I’m sure there’s some more things to build and another couple hundred thousand lines of code to write.

The March/April 2008 edition of REALbasic Developer is out. The topic of my BKeeney Briefs column was Differentiation Yourself from all the other developers that are bidding on the same job.

What are your thoughts on the topic?

“…a great disturbance in the [REAL]Force. It was like a million voices crying out in unison, then suddenly silenced.” – Will B. on Mars’ blog.

Where do you begin on this one?  It’s a sad day for Real Software that someone with that level of experience leaves the company.  It happens.  People come and go.  In the IT industry it’s been my experience that getting five years out of a talented developer is almost impossible.  I’m sure that Microsoft made a good offer from a money, benefits and long term stability perspective and the fact that it’s in Mars’ backyard doesn’t hurt either.

Yes, it will hurt in the short term though it sounds like RS has known about it for a while as Aaron has been shadowing Mars for months.  In the long term, new blood can be good for any product.  Different ideas from a person with a different background is good.  From my perspective, I just hope that Real Software’s testing program gets to work double-time on any language and compiler changes – don’t expect the beta testing program to find subtle compiler bugs!

It does concern me that in the past couple of years that there has been a lot of people leaving.  Thankfully, there has not been a huge letdown in RB features but one has to wonder how departures affect things like Cocoa, Swordfish and release quality.  New people make mistakes because they don’t have a history of the project.  Mistakes also happen when junior developers implement new features that were designated to be worked on by a veteran.  It’s not a criticism, it’s just a statement.

So, good luck to Mars.  I hope he does well at Microsoft and helps convert them to the good side of the force.