Tuesday, 29 October 2013

What software should be and isn't

I've been involved in software for over 45 years and I've seen an awful lot that is awful. The question is, what to do about it? The point of the posts on this blog will be to examine some problems and propose solutions for them.

First off, I am not an example of Dunning Kruger. 

The DunningKruger effect is a hypothetical cognitive bias stating that people with low ability at a task overestimate their ability.

I have proof of my ability and a long history of delivering exceptional results. I repeatedly take even the very latest code from people with 15 years of experience, code that took 10 hours to run, and make it run in a few minutes, without even trying hard. That is because I don't write slow code at all. Learn as much about the tools as you can. I had an employer spend 2 weeks doing something. When he asked me to look at it, I redid the same effect after only a few minutes and he got really angry.

This is the level of some employers and programmers. They are so unfamiliar with their tools, that they can be shown up easily. That should not be possible among members of a "profession".

Here's the first one. "Software as art." Software may certainly involve that which may be artistic, but it should be engineering. First reason - companies want predictability. If your system is 80% CRUD operations and 20% invention of new algorithms, it will be possible to estimate. However, the more inventions that are required, the less likely the estimate will be valid. If every line is custom, or you have the same code in multiple places, it will become the proverbial rat's nest.

The reason so many office buildings are rectangular is because that meets the need. To make an office building into a big donut is adding artistic flair to something architectural. Most software seems to me to be barely architectural and that is really unfortunate. Here are a couple of examples of what passes as art and why software developers have to distance themselves from art.

http://www.youtube.com/watch?v=He7Ge7Sogrk

An elephant can paint. Can an elephant program? Possibly. Can an elephant invent painting? I doubt it. Yet, I think we can all agree the elephant created "art". Can an elephant imagine a machine and break the design down into components and sub-components and then build a machine with said components? I really doubt it.

However, if a programmer sits down and just writes out an entire ream of code without any of the recommended architectural practices - modularization, separation of concerns, etc., are they artist or engineer? There is a lot of similarity between writing out some code and what the elephant did. Take a tool, apply it, voila. Art.

http://www.dailymail.co.uk/femail/article-2325544/Millie-Brown-Vomit-Painter-pukes-canvas-create-Jackson-Pollock-style-art-Lady-Gaga-loves.html

I don't know about you, but if the above qualifies as art, I'd much rather be an engineer. I suggest programmers become familiar with software engineering basics, because more often than not, I've seen 'art'.

Don Knuth wrote a book called The Art of Programming. That does not prove programming is an art as this book is a treatise on how to be scientific.

If you are asked to write a piece of code to count the number of weekdays between any two dates and you offer a counting routine, that is what any 8 year-old literally can do. You as a programmer should not be proud of that solution. Some form of 5/7 of the total number of days, less offsets should be the answer of an engineer.

The loop solution is O(n). The 5/7 solution in O(1). 

Why are so many systems difficult or impossible to modify? The cause is "art". Engineers make it easy to maintain and extend their creations. Artists make their creations and pat themselves on the shoulder for their creativity. Program as if your successor is a homicidal maniac and knows where you live.