Can we please stop talking about “creative programming”?
Many years ago, I had a cartoon pinned up by my office desk. It was a caricature of a pianist-like dressed man, sitting by a PC. Over the course of several sketches he got more and more excited, hitting and bashing the computer keyboard in ecstasy. The final frame showed him throwing back his hair, a satisfied smile on his face. He seemed exhausted, but happy. Alone, yet in awe of his work. Underneath the cartoon it read in German: “Der kreative Programmierer” (the creative programmer).
Fast forward to 2012 and this cartoon of the creative programmer appears to be more alive than ever. I have had it with tweets/posts/articles telling me about “creative programming” or something close to it. In my world, combining the words “programming” or “coding” with “creativity” does not compute. I find it also not helpful, because it gives the wrong impression to aspiring software developers as to what is actually involved in the task. You are not sure? Well, bear with me a little.
Welcome to my world
What is my world? For those who do not know me, I have been a SAP Development Consultant since 1998, who mainly programs in SAP’s proprietary language ABAP. There are other languages like Javascript and Flex I sometimes need to use to get my work done, but ABAP is what SAP’s applications are mainly based on, because that’s what you use to code business logic for a SAP system. It’s what this language was made for. However what I am saying is universally applicable to any programming language or development environment. Depending on the projects I work on, I also get perform analysis and gathering of requirements.
When it comes to development of business applications, best practice is to either have a design, a specification or some sort of document that tells a programmer what is required from him or her. It’s what comes out of the analysis phase. Such a specification is the cornerstone of business application development, because it is a contract between the people that requested functionality (you might even replace “functionality” with “app” here) and the ones that cut the code for it. Believe me, if you are an IT department, without such a document or agreement, you will spend too much time and money getting your developments right. If a specification or design is done right then the programmer should know pretty well what to do. There is no programming creativity required anymore at this stage, the program should cascade from the specification. In addition, there should be a standards document that gives the programmer information about naming standards, how to structure your code and how interfaces should look like, for example.
If you now say that specifications never live up to the detail they ought to contain in a perfect world, then I say: this should not be ironed out by a creative programmer, who goes away and does his or her own thing. If a specification or analysis document is below par then this reveals a poor development process in general, which has to be resolved upstream and at the source. Otherwise it’s like compensating for a bad golf swing by simply moving your body to one side. It’s lazy.
Saying this is of course not very fashionable and snazzy, especially with all the innovation hype that’s pumped out by today’s software corporations. These days, every software developer who is seeking success is easily sucked into thinking that in order to develop the next Instagram or Twitter, you have to be perceived as out there, creative, getting it. Here is the kicker: as far as the pure programming is concerned, you need to stick to agreed rules.
Am I saying that no creativity is involved ?
My answer: Far from it. But here is my criticism: No one seems to say that coding in itself is not the creative part of developing software successes. From my own experience, successful software projects are based on all or a combination of these points:
- Good, successful software is a team effort – this has always been the case in IT history and is not a new paradigm
- Analysis and gathering requirements with the actual users is important because that’s where you ensure your product doesn’t suck. It’s where you listen.
- You never design or specify software in a vacuum. Respecting boundaries (budgets, software platforms, languages, your customer etc) is important. It’s also an important difference to the work of artists, who are not limited by boundaries.
- If you develop in a team environment, you need standards and agreements that go beyond the daily programming and span entire projects.
- Finally, coding requires focus and discipline. You need to stick to what has been agreed and specified. In some cases, this is one of the last steps of a long software development journey
Just a human brain and a machine
Of course, you can sit at home and hack away to your heart’s content. I deeply encourage you to do so, because it is great for learning. You might conjure up some cracking prototypes, something that combines technologies and will be the foundation stone of IT’s future. You will still be restricted many things, but this probably is the closest to creativity you can get. It’s just a human brain and a machine – I know this can be thrilling, for sure. It might be the first of a million baby steps towards something new, but it does not resemble the creation of something that is scalable, timeless and profit making, which are the hallmarks of successfully designed software.
Successful software is brought to life not by creative programming, but by listening, analysing, negotiating and (in the end) coding and sticking to what people have agreed on. Coding is a skill, not a talent. Power needs control.
By the way: I’ve been trying to dig up the mentioned cartoon, but can’t hunt it down. Please contact me if you have it or can get hold of it.