Kevin: I love the analogy with the airport. That’s why I like TDD so much. You start with where you want to get to and then derive the starting point, so to speak. Flipping around our typical line of thinking typically leads to better designs, and adherence to the simplicity rule. I feel the same way with you with a design - if it is straight-forward, easy to understand, and meets our quality metrics (e.g. performance), all the better. Complex designs cause time and money down the road.

Thanks for the kind words everyone! I love hearing your ideas as well.

James.

Great article, lessons #1 (Keep it simple), lesson #2 (Define Done) and lesson #6 (Unit Testing) are my favorite for sure.

Regarding keeping it simple, I find it odd whenever developer relish at how complicated their code, design, etc. is. Simple designs happen to be the easiest to understand, manage and in my personal opinion they are the most elegant (I am infinitely more proud of my designs that are simple and get the job done, than the ones that get the job done but in a contrived, ‘academically superior’ way

Define done. For myself, and the developers I contract to build our product, I always define what done means (except I call them success metrics). Keeps the project within budget and on time.

Finally, on unit tests. I never appreciated these until I left MS to start my own business. If you think about it, unit tests capture the objective of the code (meeting some very specific requirement). We should all be doing this, start with an objective and aim to research that objective. Best analogy I know of, when you go to the airport you start with a destination in mind and you take the appropriate flight to get you there, not show up at the airport and jump on any old plane

Great stuff, MS needs to start cloning you

–Kevin

In my job, I parachute in very late in the dev cycle–unfortunately too late to implement these best practices. However, what I can do–& will doo–is evangelize them in the hope that they’ll be used in the next project.

I would agree in principle, but in practice with languages like C++ and C# (without extensions like Spec#, or whatever the name changed to), unit tests provide that safety net we need to refactor confidently and validate our thinking, as well as drive the design. Verifiable languages would be a nice addition to the arsenal of development weaponry, and even catching with C# catching up to other languages that natively support Design By Contract as a start would help with validation.

Would love to hear your other ideas, Corey!