Sunday, March 22, 2020

Software is not a Science

I've been coming to a realization that one of the great problems with software development is the fervent belief that it can be simplified, that it is a science that can be nailed down to a fixed set of guidelines and will thereafter magically be perfect.

It's not. It's simply not. Like it or not, writing software is a creative aspect. You can no more reduce writing software to a set of fixed answers than you can create a checklist for drawing artwork.

Let's think about this.

First off, creating software requires the development of a unique solution to the problem from a set of incomplete tools which need to be assembled into a final system. It's a lot like building with Lego -- but you don't have the advanced set with all the fancy pieces. You have 2x2s and 2x4s and a couple of 2x8s.

It gets better. Normally the problem isn't even that well defined. You have a Lego set but you don't have the instruction sheet and the box is torn so you only have half the picture.

Of course, we do have the continued advance of software development - new systems, new languages, new processes. These are all great and fancy things. These are Space Lego, and Harry Potter Lego. They let you more easily create the new worlds you are imagining. But they don't remove the creative element - you don't automatically get Hogwarts, you have to build it. That's how you bought Castle Greyskull, but not Hogwarts.

Most of the development processes that we develop fall into two categories.

The good ones aim towards giving us the instruction sheet. A set of processes that advance us towards our goal - with the understanding that it will help us build THIS product. We can use bits and pieces of one instruction sheet - creatively - to help build other products. But naturally you need to intelligently apply your creativity.

The bad processes aim towards removing the random creativity element, assuming that all problems can be solved in a fixed, predictable manner. Problem A is given to developer B who applies solution C, which takes time D. Neat, tidy, and guaranteed quality output. About as likely as Gingerbread men inviting you to tea and gumdrops, but we invest thousands and thousands of dollars in pursuit of this goal.

Software needs to be run more like art. Unfortunately, I don't have insight from professional artists on how it runs and whether it works for them. I'll need to do some research. :)