Recently I wrote about Tom DeMarco’s claim that software engineering is, in some sense, a ‘dead’ discipline. In many respects, I think he is right, especially in pointing out that a narrow focus on 'engineering’ concerns is no longer appropriate. Engineering is about making something that carries out its stated purpose in an efficient and reliable manner, but it cannot tell us whether or not that purpose is a valuable one.
I think it’s worth expanding on that insight a little further, particularly as it affects me in my job. I am, fundamentally, a coder by trade and my job still requires me to be able to write good code. Given that I’ve been writing code since primary school, I like to think that I’m now reasonably good at it. But when I was 18 and thinking ahead 10 years, I thought that being an ace coder was the only thing, professionally, that mattered, and it isn’t. <!–break–> Don’t get me wrong, I still think that it matters a lot. Being able to write good code in one’s chosen language(s) is a pre-requisite for anyone who takes him/herself seriously as a software developer. But the narrow conception of the software developer as a code monkey or savant hacker finding self-expression in the depths of a C++ program just doesn’t seem to exist in reality.
Software development in 2010 is a much more multidisciplinary subject than the public perception of software development recognises. To be a good developer, you need to understand -
If you want people to use your software, you need to understand how they relate to it. What makes software usable, intuitive, comfortable and reassuring for people, and what makes software confusing, irritating and unfriendly? What problem is a person trying to solve with your software and how can you make it easier for them?
Why should people buy or choose your software? What’s the payoff? How to structure pricing and incentives is very important: obvious examples include mobile apps and subscription-based web2.0 services, but there are plenty more. Of course, economics goes a lot further than “how to sell your product” and a good grasp of economics will teach you much more: incentives, coordination problems, economies (and diseconomies) of scale and the benefits of specialisation and trade, for starters.
Business and organisations
There has never been such a thing as a self-contained “computer system”, but it’s now harder than ever to pretend that there is. Networks are everywhere, and software - your software - forms a small part of a chain that will include people, networks and other software. Where does it fit in and what problem does it solve? How does it co-exist with the rest of the system, human and machine?
This is a somewhat controversial point, but I think that software needs to be beautiful to be truly successful. And I don’t just mean that the code should be elegant (because often it isn’t). A great work of art can be appreciated even by people who cannot comprehend how it was made, or by those who do not typically see beauty in such works. This doesn’t mean that software needs to have eye candy, it just means that software needs to feel 'right’ to the people using it in the way that a good painting or piece of music feels 'right’ to the viewer or listener.
All of this can be summarised by saying that software must be useful. But there’s a lot more that goes into making software useful than most people would commonly imagine, including most people whose job it is to make software. I once thought that it would be all about being able to optimise subroutines or create perfect data structures or choose the right design patterns, but software development now is all of those things and more.
This flies in the face of the stereotype of the software developer as someone who doesn’t understand people and doesn’t particularly want to. If such people really exist, then there’s always going to be a place for the ultra-focused hacker who can code anything 10x faster and more reliably than his or her colleagues, but to progress from designing code to designing systems requires a different skillset. The challenge for my generation of software developers is to take what we know about code and computers and combine it with new knowledge and understanding of the world around us to make software that delivers benefits great enough to justify itself.
Footnote: In the title of this post I said that software developers are not “just” engineers. I do not mean this in the sense of “mere” engineers; I mean that engineering is one specialism within software development and not the only one. Software development is a team game and teams need good engineers as much as they need good architects and project managers.Share