Programme development is often an inverted process. A lot of thought goes into research and design, while the actual coding is haphazard. This is why test driven development is so important.
I learned how to code the way I learned how to cook. I followed a recipe, then I improvised and checked the end result. I began coding by transcribing programs from Compute! magazine. This gave me typing skills, concentration, and attention to detail. Invariably I would make a typo and the code wouldn’t work or would behave differently than written in the article. After I got the programme working, I would modify the code to see what would happen. Unfortunately, this lead to bad habits including coding first, then adapting the design to match.
Computer courses in high school and university pretty much reinforced these bad habits by teaching the library of functions first, demonstrating their use, then testing how well they were learned. With the number of methods and attributes available in the libraries of class object, learning all of them is impractical. The first and only class that I took in university to invert this behaviour was a software engineering course which focused on the flow of data. Before any coding was done, before even choosing the language and hardware, the overall highest level black box system had to be designed. Then step by step, details would be added level by level until it was parsed out into several independent, interrelated objects, each of which could be coded, constructed, attached, or otherwise delegated. I have been using this approach to programming ever since.
It’s like when video game systems were built in the eighties that had a video screen, a joystick and buttons, and a coin slot. When the product was ported over to the home console, it didn’t work the same, probably because the whole thing had to be rewritten with the coin slot written out, the integrated joystick written out, the custom electronics written out, the video size and resolution was different. The design wasn’t thought out to include different architectures.
It wasn’t until recently that I stumbled upon test driven development, shortened to TDD. This was known when I went to university, but it wasn’t taught. I am pretty sure that the upperclassmen and professors that taught the courses knew about it, but whether they practiced it did not come out in how they taught the courses. But it would have helped with their assignments. A lot of my classmates dropped out of programming because of the length of time they had to spend on debugging their code. Those who dropped out early, mostly women, were smart to do so because of the bad habits that were reinforced by the teaching methodologies. Those that took only a few hours a week coding must have known some secret sauce that they learned before university. I suspect that TDD was that secret sauce.
TDD is a methodology of breaking your code before you write it, then fixing it. That is, you write a test that supports your design before you write the code that confirms the test in just three or four lines; ten is too many. Then you spend time modifying the code to make it faster, more general, and more legible. You could develop your system top down or bottom up, but in the end it takes less time because it takes less debugging. I could demonstrate by talking about a function that returns the square of a number, entering a test that takes the value of 2 then returns the value 4, and write a function that returns 4 no matter the input, then refactoring, BUT there are a lot of tutorials on the subject so I won’t bother.
So many projects are heavy on the design with not enough spent on the implementation. Project managers are very easy to please; they are satisfied by the very best. But programmers that don’t use TDD aren’t doing their very best. Mistakes creep in initially, then flood in when it’s handed off to another developer. If designers are measuring the project with a micrometer, we programmers better mark it with our sharpest pencil, rough it out with our sharpest chisels, test it with our best calipers, and sand it down with out best sandpaper with coarse to finer grit.
