What is software development? An art? Craft? Trade? Occupation?… Part 3

In the previous two parts we have seen that software development is a very large collection of technologies and methodologies, and an area that has been in constant development since the advent of computers. However, even though every few years there are new ideas that are all the rage, and presented as the ‘silver bullet’ to solve all our problems and massively improve the quality and productivity, it seems to fall flat on its face everytime, once the initial hype dies down. In this part I would like to look at this from a different angle, and try to find some things that DO actually work.

Are new things really new?

In past blogs, I have given some examples in the past of ideas that aren’t really new, but can be found in papers or books published decades ago. I recently found this presentation by Kevlin Henney, that goes much deeper into this, and gives a great perspective on these ‘new’ ideas:

He gives a number of interesting historical examples of things that people consider ‘new’ today, but apparently were already being discussed back in the 1960s and 1970s. Some examples include abstract datatypes and objects, testing and iterative development.

This brings us back to Parnas (and in fact, a quote from Parnas from the 1970s appears in the above presentation by Henney). Because in his ‘Software Aging’ article that I mentioned last time, Parnas mentions exactly the type of thing that Henney discusses: A lot of ideas are already around, but they are not being communicated well throughout the software development community. The ideas are either not known at all, or they are not understood properly, in the context they were meant. As a result they are also not taught to new developers.

Now, when I talk to the average Agile/Scrum-fanatic, it appears that they think they finally found the answer to software development, and all those old developers simply were just messing around with waterfall models, and didn’t know what they were doing.

I think Henney proves a very important point in his presentation: These people DID know what they were doing. It is those people who think that these ‘new’ ideas are really new, that don’t know what they are doing. They are ignorant of the past, and are reinventing the wheel to a certain extent. And it seems that it comes down to the usual ignorant-arrogant pattern that we often see with the Dunning-Kruger effect: In their ignorance, they assume that they know more than the others, so they assume that their ideas are new, and the people before them weren’t as smart as they are.

It had to come from somewhere…

Now, if you think about it some more… Object-Oriented Programming (OOP) has been around for a long time now. The whole concept of Object-Oriented Programming had to come from somewhere. People didn’t just get together and think: “Let’s design some new programming language… here’s an idea! Let’s put objects in there!”. No, the concept of objects existed long before that. OOP languages are basically syntactic sugar for programming in a way that people even did with Pascal, C and assembly: working with objects.

It just seems that these ideas were forgotten or poorly understood, so when new generations of developers started learning object-oriented programming, they were not taught the right way. They understood how to write a working program in an object-oriented language, but they don’t know the languages that went before them, or what problems object-orientation tried to solve, let alone how best to solve them.

Now, Design Patterns will give you some examples of good solutions, but still I am missing something: nobody seems to tell you what the idea behind it is at the lower level. Let me try to give you a quick (and somewhat simplified) example:

An object can be seen as two sets of data:

1. The actual data that is stored inside the object
2. The methods of that object, laid out in a table

Methods are data? Well yes, they are function pointers. Methods are nothing other than procedural functions where the first argument is a pointer to the object. That is how inheritance and (virtual) methods work: You can store a function pointer inside the object itself. So if you pass an object to a method as a parameter, you are also passing the functions that should be called. So the object decides which function is called. The interface decides how the table of functions is laid out, so that index N in the table is always DoSomething(A, B, C) for all objects that implement that interface: it is a ‘contract’.

And when you understand objects at that basic level, it makes sense to just use objects and interfaces to pass function pointers around, so you can perform specific callbacks on that object from other methods and objects. And then Design Patterns such as Strategy and Bridge may suddenly make a lot more sense.

And of course you will also understand that people were doing this long before the Gang of Four published their book in 1994, and long before object-oriented programming languages were around.

As for hype… I have mentioned the No Silver Bullet article by Fred Brooks many times already. Even way back in 1986 he already warned about ‘new’ technologies and methodologies, surrounded by a lot of hype, which never seemed to deliver on their promises.

So clearly, there are some very good lessons that can be learnt from older sources. They are out there. You just need to look them up. Stand on the shoulders of those giants.

Get to the point already!

Brooks describes the ‘great designer’. Donald Knuth titled his most famous works ‘The Art of Computer Programming’, and has described programming as an art and a science. There is a very interesting study done by Barry W. Boehm in his book ‘Software Engineering Economics’, where he asserts that the key driver of software cost is the capability of the software development team. There is the concept of the ‘10x programmer‘, which was first seen in the paper ‘Exploratory experimental studies comparing online and offline programming performance’ by Sackman, Erikson and Grant in 1968. Joel Spolsky has pointed out that you should be looking for an ‘aptitude’ in programming, in his Guerrilla Guide to interviewing.

The constant here appears to be the ‘human factor’, not some kind of ‘magic’ technology that you have to use, or some kind of ‘magic’ methodology that makes everyone a great developer. It is about individual people, their talents, and their knowledge, skills and experience. The talent is something you cannot control. Knowledge, skills and experience you can improve. You can train yourself to become a better developer. You can train others to become a better developer.

And that brings me to the actual point here. As the title suggests, you can view software development in many ways. Viewing it as an art or a craft makes a lot of sense in this particular context: just like other arts and crafts, you can improve, and aim to master your craft. And you can guide less experienced developers to also become better by giving them proper advice and guidance.

This brings me to another recent movement in the world of software development. One that perhaps does not quite have the marketing skills of the Agile/Scrum movement, but their ideas are certainly no less valuable. On the contrary. I am talking about ‘Software craftsmanship’.

They try to make you view software development as some kind of medieval guild. And of course they have also drawn up their own Manifesto. For now I will leave you with Kevlin Henney once again, with a talk he has done on this subject. It aligns nicely with some of the things I have said on this blog before, and some things I haven’t:

Advertisement