This is a question that I really hadn’t thought about explicitly until I came across it in a book recently. While it might seem to be a trivial or even irrelevant question at first, it takes on greater meaning when one thinks about it for a bit.
When I first started programming – many years ago – in FORTRAN – using punched cards – on a machine with 8K of memory and a 512K hard drive – I did it because it appealed to me and it was … fun! Nobody told me to do this – I just wanted to do it.
I suspect that a similar story (differing in some of the details) could be told of most people who work in software development. I’ve never seen any figures, but I doubt that many people decided to get into software development because it was “just a job” and they could have just as easily chosen to be a car salesman or a cop instead.
And it is also the case that virtually every activity, no matter how much fun it inherently is, has aspects that are not so much fun, or can be managed in such a way as to maximize or minimize the fun. For example, cleaning up after a fun project is usually not so much fun, and if you are on the baseball team, you’d probably rather be batting than doing pushups.
Why, then, is this relevant?
If programmers are creating software because they think doing it is fun, and because everyone here (programmers, managers, sales people, etc) wants to see more software produced, it follows that we should try to maximize the fun parts of software development while minimizing the “non-fun” parts. So which is which?
According to the book I just read (as well as my own personal experience), I would classify a few things as follows:
|Not (as much) Fun
Generally, fun things are those which are creative and which resulting in constructing something useful.
Things that are not fun are those things which are perceived as bureaucratic or that appear to stand in the way of getting the code done.
This is not all that scientific or complete, but I think it generally rings true for most tech people.
It tells us why CMMI and similar initiatives are not well received by software creators – it is because they emphasize and require bureaucratic work such as documentation and meetings that most programmers find to be obstacles blocking the way to the creation of code.
Testing is an interesting thing. All programmers realize that it is necessary, but few like to do it in anything other than tiny quantities. That being the case, we need to find ways to get it done as quickly and efficiently as possible. Automation comes to mind.
Agile methodologies tend to be preferred by most programmers because they minimize the creation of non-code artifacts and allow the practitioner to get down to the “fun” stuff as quickly as possible.
I’ll quit here and leave your imagination to triage some of the activities we face in development to figure out if they are fun or not (what we can do to maximize the fun – and thus the output and job satisfaction). I think that software development should be fun.