On Software Engineering

A number of these phenomena have been bundled under the name “Software Engineering”. As economics is known as “The Miserable Science”, software engineering should be known as “The Doomed Discipline”, doomed because it cannot even approach its goal since its goal is self-contradictory. Software engineering, of course, presents itself as another worthy cause, but that is eyewash: if you carefully read its literature and analyse what its devotees actually do, you will discover that software engineering has accepted as its charter “How to program if you cannot”.

Programming is increasingly being used by a number of people across the planet. However depending on their background it might have various use-cases. For scientists, it can be a tool to generate interesting results for examples. Data scientists similarly use it generate insights and train models. However Software engineering as a discipline has different Goals. Software Engineering is about requirements elicitations and Converting the requirements into bug-free Code(easier said than done). It also involves Writing Readable Code. The SE Code write is not written to only be understood by computers but by fellow programmers as well. Software Enginneering has the additional goal of keeping Complexity down and allowing extensibility by following the principles of Encapsulation, abstraction, loose coupling and modularity.

We wrote software to send man to the moon, so is it a new discipline? Well, Unix culture gave us the unix philosophy and thats where it all started and even though it might be outdated, I believe it still hold nuggets of wisdom. e.g Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface.

The Principles of Agile Manifesto and the Zen of Python are guiding principles that also hold in them great wisdom. These three cover the core principles of what S.E courses or books try to teach you. If followed religiously, they can ensure better high quality products and taming Wild Software Schedules.

Software Project Management has three major Goals:

1. Gather Correct Project requirements
2. Manage the project costs so that there are no cost overruns.
3. Ensure an on-time delivery of a quality product(which is related to point 2) because Engineers’ time adds to Cost of dev.

The process we follow is mostly about creating enough discipline amongst the team, so that we can smoothly go through the development stages with ease. Why do software project fail then? Well we tend to forget the history and perhaps we our insistence on treating software engineering as an engineering discipline is flawed.

Metaphors for Software Development

Hamming in his talk argues that writing software is not applied Engineering. Engineers others than software Engineers are bounded by the laws of physics... He goes on to say that if you give two programmers the same problem they’d come up with entirely different solutions just like writers writing on the same topic. Thus you cannot Engineer software because its a product of mind and perhaps is much closer to writing a novel.

In pragmatic programmer author argues:

Unfortunately, the most common metaphor for software development is building construction. [...] Rather than construction, software is more like gardening--it is more organic than concrete.[...] You constantly monitor the health of the garden, and make adjustments (to the soil, the plants, the layout) as needed.

Similarly, Don Knuth introduced the paradigm of literature programming. 'The main idea is to treat a program as a piece of literature, addressed to human beings rather than to a computer.'

If we can't engineer software, this then begs the question, how do you become better at this game of creative activities such as writing code or writing novels?

Hamming says programmers or writers can get better by critiquing their own work and holding themselves to a higher standard. But its easier said than done. I would add that its rather important to first develop good taste in whatever work you are doing. This can be done by first studying great work and understanding what makes it so great? Once you learn to distinguish between good and bad work, you become a better critic. Self-criticism is at times hard because we usually think our ideas are always good and there is a emotional attachment between us and the work we produce or things we build. So my suggestion would be to take a relatively long break after producing work and come back later for analysis and try to rank your work on some scale of good to bad.

Software is an artifact that needs to be crafted with care. This makes computer programming an art, because it applies accumulated knowledge to the world, because it requires skill and ingenuity, and especially because it produces objects of beauty. A programmer who subconsciously views himself as an artist will enjoy what he does and will do it better. Therefore we can be glad that people who lecture at computer conferences speak of the state of the Art.

The complete talk by richard hamming is really interesting and is worth listening to. Paul Graham has written about taste as well.