Know Your Code Response

I couldn’t agree more, and for what it’s worth, add my “philosophical” rants to your example. My first programming journey’s were on the old Sinclair ZX Spectrum in the early ‘80’s (using tape drives no less connected to TV’s for monitors). One thing early programmers prided themselves on was mastery of their present development tools. In the pre-Internet age, time consuming manuals and any peer publications were all one had to assist the process, so a thorough understanding of what was needed and how this could be best achieved was required before ever attacking the code; not to mention the processing time required to compile and test. Things had to be extensively analysed to minimise wasted “iterations”. Back then we could not afford to have to many iterations, nor could a project succeed without senior experience, monitoring the junior short-sightedness.

In today’s fast paced culture, where complex systems (even architectures) compile at the click of a button, and “Agile”/”RAD (rapid application development)” methodologies are becoming the norm, coding can become rather lazy. It was difficult for an old programmer like myself to transition from being “master” of his domain, to “Internet researcher” of project objectives. Sure progress has its advantages, and I greatly appreciate frameworks and tools like .NET and the work they alleviate from the mission objectives, but there is one point that I think is lacking in the modern psyche…An understanding of the consequences of an approach. Given a task, the Internet presents seemingly endless possibilities on how one could achieve that solution, but just because a spoon can technically cut a steak, it doesn’t mean it is the best way to do so.

On this journey, I have made many mistakes myself, thinking I found a short cut, and with frameworks like .NET, the negative consequences can often be covered up until the solution is stress tested. I have found the transition was more from technology “master” to technology “manager”, but I fear that our increasingly quick short mission objectives à la RAD is threatening the quality of what is produced. We must not sacrifice a proper analysis and thorough understanding of the technologies used, for simply achieving our mission objectives in record time. Experience has shown me that a little extra time considering the best technological approach (in particular the impacts of a chosen implementation), often reaps much saved time having to redevelop core foundations later; it is easy to add and modify features, but much more difficult to relay a foundation. For me, iterative development methodologies should only deal with peripheral features, not core components. When it comes to the core of an application, I don’t think we can get away from the more traditional approach, and this takes time; time that is not wasted.