Innovation Isn’t Driving the Software Development Process

Software Development Isn’t An Art IV

Let’s face it. The software industry just doesn’t eat its own dog food.

Debuggers? What are they for? Why doesn’t the system point out when memory is clobberred or a pointer is NULL?

Hardware is cheap. Software development costs are much higher. Why is that? Hardware developers have no trouble using simulators in the development process. The cost for building first-runs is quantifiable, as is the errors and rework associated with them. Hardware engineers and their managers can see the cost of defects in manufactured products is too high not to use additional tools, such as mock-ups and prototypes, to aid designers. So why don’t software projects also use simulations and other tools to improve the quality of the process? Poor management. Proud and arrogant developers.

Programming today is done much the way animating was during the twenties, before Walt Disney pushed for process improvements in his studio. After a director selected a storyline, the animators would have to produce a certain amount of feet of film, and come up with the gags and bits of story to fill it. Then the work produced by the various animators would be spliced together and, hopefully, they had a reel where each animator’s contributions formed a somewhat coherent plot.

Visual gags were a requirement because the story and character development were not considered important. So the use of gags and other gimmicks became necessary to sell a cartoon to film distributors.

Code shouldn’t be designed as it’s written. If you believe this contradicts the agile philosophy, in particular XP, you’re probably opposed to TDD as well which is a heavier process method than just straight writing code. Writing the actual code to be used in a production environment should be one of the last steps in the development process. A lot of effort must go into reviewing and validating the requirements, the implementation languages and the development toolchain, the architecture and interfaces, the components’ roles and interactions, the execution platform, etc. before the production code itself can be written.

If you do not have the behavior of the code firmly in mind before you begin writing it, you cannot reasonably expect it to behave well with others, and you will be doing a lot of rewrites. And debugging. A lot of it.

Leave a Reply

Your email address will not be published. Required fields are marked *