Eppur Si Muove

 
 
Im always experimenting; looking for ways to be a better developer.  Here are a few of the practices, that as I look back over the last 10 years, I feel have made me a more effective developer
1) tracer bullet design
When I'm thinking through a design I find that its really helpful to skip the UML diagrams and work out the design directly with a shell of empty code.  I will write the interfaces.  I put in some implementations but they will be just empty shells with no actual code realized yet.  This allows me to experiment with different naming conventions and see if I am communicating my intent through the language.  With code in place I can see how dependencies develop between modules.  Naturally, I can also compile my work as I go along as well.  Being able to compile helps me to catch any potential mistakes in my thinking; it holds me to a rigorous standard of correctness.  And lastly once I am done and satisfied with the design, I have code.  I may even have a build system in place.  Having code is a tangible result and that counts more to me than a set of pretty UML pictures.
2) Unit testing
People thing that unit testing is a practice that will decrease bugs in delivered code.  In my experience unit testing doesn't catch a lot of bugs.  Rather the main benefit from unit testing is that it has changed how I write code.  I have been forced to develop code that's more abstract and more configurable and less coupled because that style of code is the only code that can be tested easily.  On the same idea I find it very useful when learning a new language to do a lot of testing .  Testing provides quick feedback which is nice for learning; it also forces one to learn the idioms that language provides for abstraction.  Lastly, I should also mention that an important benefit from writing unit tests and having good code coverage, is that one can refactor with confidence when ones application has to undergo change.  Without that coverage there is no way to rework code with confidence on a large project -- one is stuck with the past and trying to money patch as one goes along.
3) Design by Contract
Its really hard to write correct code and write robust code.  Thinking in terms of preconditions / postconditions / invariants, adding asserts to code, has all helped me to write correctly working code the first time through.  I also find that thinking in terms of DBC, along with unit testing,  changes ones thinking towards a more specification oriented frame of mind.  The thinking is more rigorous, that influence works it way down to the code.
4) Dynamic Languages
For fast development go with a dynamic language, an IDE that supports that language and a debugger.  As an example, I worked on a supporting tool for our main project at work using Groovy in Eclipse.  The tool was of fair complexity and it was finished in a week.  Comparing the development speed to comparable tools I have written in Java, I would say I was at LEAST twice as productive working in Groovy and there were no negative effects in other areas.  That said, I'll just emphasize the productivity seems to be not just a function of a dynamic language alone.  I also develop for my own pleasure in Clojure / Slime and I don't see the productivity gains there.  I've done a fair amount of Perl in emacs; good productivity but no huge gains there.  Also, as a slightly non topical reference point, I haven't seem much in the way of gains using Haskell in emacs.  My explanation is that using dynamic language along with the full support of an IDE sets the basis for remarkable productivity gains from day one of working with that language. 
And you? What practices have been valuable to you as a developer?



Leave a Reply.