Planning not to fail in software development

As in building construction, the success or failure is mostly pre-determined during the preparation phase through processes such as blueprints, surveys, permits etc. This applies to software too and doing the most expensive part of a big project twice is not good, just like bringing down a skyscraper which is halfway done.

High quality practices in software engineering emphasize on quality at the beginning, middle and end of a project. This begs the question of what constitutes quality at the beginning? They include problem definition, coming up with a solution and designing the solution. The main goal is reducing risk which might come up as development proceeds.

However, the argument might look pretty solid on paper but in reality most programmers mostly suck at it, we just want to code. Training isn’t mostly focused on these skills such as business cases, comprehensive requirements and high quality architecture designs. For those of us who can, there are additional compelling reasons not to which with a little experience can be tamed with a lesson or two, learning from past mistakes, which is the best teacher. If the boss is the issue, part of your job is to educate non technical people about the development processes.

So where to start

Determine the kind of software being worked on which in our case isn’t a small toy project. Choosing an approach to perform this prerequisites becomes the next step which might be sequential, iterative or a mix of both. I tend to lean on iteration which is much flexible in practice since a single step cannot be fully exhaustive and predictability in software can and is described as software heaven, only in your wildest dreams. Now comes the various prerequisites

Problem-Definition Prerequisite

It defines what the problem is without any reference to the possible solutions. A good problem, if there is such, should be in a user’s language or point of view and just like I tell most people that come up to me with great ideas, “the best solution might not be a computer program”. The penalty for failing to define the problem is wasting a lot of time solving for the wrong one just like in high school math problems.

Requirements Prerequisite

They describe in detail what a software system is supposed to do. They come in handy by ensuring the user rather than the programmer drives the system functionality, avoid pointless arguments in a development team and minimizing changes to a system after development begins. However, stable requirements are a myth, “a holy grail of software development”. The development process helps customers better understand their needs, plan for change! Set up a change control procedure since most “must haves” are “nice to have”. Additionally most requirements disappear when business reasons come to mind, don’t kill yourself trying to be fancy start with the basics.

Architecture Prerequisite

If it doesn’t make sense to you, how can you implement it? Architecture is the high level design and the quality determines the conceptual integrity of the system. Good architecture makes construction easy while bad architecture makes construction almost impossible. Describing motivations for all major decisions while providing for considered choices & alternatives while being as machine or language independent as possible. Some of the components include but not limited to:

• Program Organization
• Data Design
• Business Rules
• Security
• Performance
• Scalability
• Error Processing
• Architecture Feasibility

It pays to do things right the fist time. Unnecessary changes down the line are expensive!!

Additionally, it’s important to have the right tools before heading out to work which in our case is achieved by focusing on the preparation that individual programmers and technical leads are responsible for. These include choice of programming language, programming conventions, position in technology wave and construction practices.

A developer is more productive using a familiar language than an unfamiliar one. Although it might not be as impactful now, considering the high level programming languages we have that share very similar syntax, the choice is still critical considering one is immersed in it from the beginning of construction to the end, which there never really is in a program’s life.

One key to successful programming is avoiding arbitrary variations so that your brain can be free to focus on the variations that are really needed. That’s the place for programming conventions which are especially handy in teams. It is nearly impossible to change code to match them later.

Technology evolves so fast that it sometimes hard to even keep up. Have you tried showing an old folk how to use some very “basic” software. Programming languages are no different and I might say they’re more susceptible and can feel like a popularity contest. How then do you keep up depending on your position in the technological wave i.e. early, middle or end? Just don’t limit yourself to one. There is a great distinction between programming in a language vs. programming into a language. If you can drive a Toyota given a Lamborghini or a Tesla, shouldn’t essentially be any different.