Make It Work, Make It Right, Make It Fast

Today is our first ever reader contribution from Brian DiCroce

Our font today is called "j.d." See bottom of post for details.



Content Source: Kent Beck at C2.com wiki

When working on a feature, let yourself be driven by this little principle to actually get things done right.

Make It Work
Program with your mind focused on the feature's basic behavior. Just make the feature work. Ensure that all the test(s) pass for that feature.

Make It Right
Now that you have your feature working (all tests passing), focus on refactoring the code. Tests will provide the necessary feedback. Clear up structural and aesthetic issues, remove duplication, rename variables, etc.

Make It Fast
Once the the tests are passing and the code is clean, you can focus on tweaking its performance. Use a profiler of course. Once again, you can feel confident in your changes because the tests will ensure that functionality is not broken.

I abide to this principle whenever I'm developing a feature. It help to shift my focus toward specific development efforts when working on a single feature. The initial effort is toward getting a feature working for quick feedback from users (or potential users). Improvements can be made after the fact, making the code faster and smaller.

This principle is easily applied in conjunction with TDD. The test-first approach helps me drive the design or API of the feature, while the pre-existing tests ensure that the rest of the system continues to function correctly. Refactoring can be applied naturally and at will as the new tests provide a safety net for the code. With the functionality assured, performance improvements may be added with confidence.

If your quick-running, hand-optimized system does not do what it is suppose to do, it is not worth investing time and resources in making it any faster. After making sure that the feature works correctly, you can focus on the performance of the feature. Once again, the tests act as a sidekick in that they will continuously provide you feedback whether changes broke the system.

About the font:
"j.d." is a windows/macintosh truetype and postscript type 1 font, handcrafted in the Emerald City by Steven J. Lundeen, Emerald City Fontwerks, Seattle, Washington, USA.
Generously released as freeware, and copyrighted ©2001.

4 comments:

  1. again love these things, how close are you to being finished?

    I've done a very quick review here...
    http://agileconsulting.blogspot.com/2009/03/agile-in-flash.html

    Regards
    Jeff
    http://agileconsulting.blogspot.com

    ReplyDelete
  2. see my note in the other post, and please contact me. We're moving along at a pretty good clip, and at one time had 80 cards (not all were "winners" and my only appear as blog fodder).

    ReplyDelete
  3. Thanks for the great blog post Jeff! Once we get around 60 cards on the blog site, we'll go back and pare down to a core 52. I hope that's within a month or so.

    ReplyDelete
  4. I think Kent isn't the one who originated this advice, although he may have coined the mantra. See http://research.microsoft.com/en-us/um/people/blampson/33-hints/webpage.html (Butler Lampson). Kent would know, we should probably ask at the point where we ask permissions.

    ReplyDelete

Note: Only a member of this blog may post a comment.