Software Development

I like finding people who have stumbled upon the same best practices I have.  It makes me feel less lonely in the universe.  Friday night before the St Louis Day of .NET I was able to attend the speakers dinner at Granite City Food and Brewery in Creve Coeur (great food by the way, Mediterranean Chicken was a good choice for a late dinner).  At my table was Jim Chandler (speaker), Eric Brown (speaker), Jeff Fattic (Organizer & Speaker), Michelle Marcus (one of Jeff’s minions), and JD Wade (Speaker), .

As the evening moved on we started discussing work related things.  The big topics were unit testing, source control, process, and good design.

On Source Control – I was amazed to hear that there are companies, big ones, who do not use this.  I don’t think we use the best source control available at REJIS but we use it and it has saved us many times.  The potential for damage is huge when that source code is what drives your businesses systems; you definitely want that stored somewhere safe.  Yes someone can always mess with things in source control but that is why rollback was invented.  If you don’t have it or aren’t using it, get source control.  There are free, open source ones and ones you can pay for.  Get one, use it, and follow best practices for using your particular source control software.  And don’t forget to back it up regularly…

On Process – This one ties in with design (below) and source control.  As Jeff Fattic put it, "no process is bad process".  Everyone has a process even if it is bad.  The key is finding a process that works for your team and using it.  Having a bad process is not going to guarantee results.  A good process gives you a much better chance of guaranteed results.  You don’t have to pick an off-the-shelf process such as agile or any of it’s derivatives.  Process should be the steps you go through to identify, document, design, construct, and maintain a system.  In my opinion this should be something that is iterative and can handle change.  Waterfall (big design up front) worked a few times in the 70s but it doesn’t now so rule that one out (the whole table agreed on this point).

On Good Design – The big joke that I wanted to use in my Oslo speech was asking if anyone who used UML had ever looked at what was finally developed to see if the UML and the system were in sync.  No one in my morning session used UML.  Only two in my afternoon did and they laughed at my joke. 

I was an artist back in high school, before I got heavily into coding.  When I started coding it was like art to me except I made the computer do something.  I wrote neat programs and systems with not much aforethought and no drawings or diagrams.  I had no training in software development, I just coded.  It turns out that this is the majority of developers today.  Developers just code; design is what someone else who has more time does.

I have seen the effects of insufficient design.  I did not like those effects.  I made it my quest to find out how to design good systems, what tools to use, and when to start.  I argued with people about it and eventually demonstrated how good designs, good architecture, would save a lot of headaches later.  It is not easy to keep UML diagrams that are not directly updated by changing code up-to-date.  Designing extensible, maintainable, and scalable systems isn’t easy either but the up front work always pays off.  Even if you just design systems on a whiteboard at least take a picture of it so you have something.  If you want more on the subject read Steve McConnell’s Code Complete Second Edition.

On Unit Testing – Before Visual Studio 2008 I did not unit test.  I had heard of things like NMock and other test frameworks but did not understand why it was necessary and it seemed like extra work.  My tune changed quickly after I dove into what unit testing was about and I realized how much it would save me later.  I am one of a few who actually use Unit Test projects in VS 2008 at REJIS.  Everyone does functional tests and "screen" testing but not necessarily unit testing at the class level which is where mots of the problems happen.

Unit testing matters and good unit testing makes all the difference.  I don’t think I write great unit tests but the ones I do write have saved me and have saved other developers from mistakes that would have went into production.  Recently I found a unit test that was not sufficient and we had to correct something that was out in production.  Mistakes happen.  Unit testing minimizes those. 

Eric asked a good question:  If you have a class that mimics a basic calculator with four methods: add, subtract, multiply, and delete, how many tests should you write at a minimum?  I think, after our discussion, the answer is at least 8.  One to show how each method works and one to show how each can be broken.  A good example for a "break it" test for the add method: Integer.MaxValue + 1 (Kudos to Jeff, he thought this one up).  What should happen there?  Now think about your own classes, don’t just test to make them work, test to make them break because sometimes those tests can be just as revealing.

Having dinner with such a group is great.  It reminds me that I am not alone and that my opinions are well-founded.  I don’t make a habit to constantly hang out with people who have the exact same opinions as me.  I would never learn that way.  When it comes to best practices I don’t think its bad to surround yourself with people who share the same views.  Best practices are just that; things that you should be doing because they are proven to be successful and will give you a competitive edge.  Here’s a few things you can do to get started:

• Even if you aren’t aspiring to be an architect study good architecture.  Good architects need good developers who will stick to the architecture and make the system work within its defined boundaries.  There are reasons for those boundaries and a good developer should understand those too. 
• Learn the different source control systems and discover how they can compliment or affect your development process.  Discuss them with your team.
• Have a good process that works for your team.  It doesn’t have to be agile or scrum but do look at standard processes and take the parts that fit your culture.
• Test your code.  You are not perfect and no one expects you to be.  If you correct a huge problem before it is a problem you look much better than you look when you are trying to explain how that error wasn’t caught and is now costing your company or customers money.  Trust me, I have been on both sides of this. 

Here are some local personalities that have some things to say on best practices and keep their blogs flowing:
Jeff Fattic
Muljadi Budiman
JD Wade
Clint Edmonson
Denny Boynton