Good code

What’s good software?

From end-user point of view - it’s software that does what it supposed to and is bug-free. In simple words, when we do use requirements analysis - that all requirements - functional and non-functional are met. If software was built on demand - customer defines the requirements, if the product is general off-the-shelf solution - customer is free to choose between solutions and find out what more fits his or business needs.

Managers and sales care about reducing costs and increasing profits. Less time spent on developing new feature means success (and more time to spend on other features).

Software developer thinks of many things. I can be sure about it. Family, friends, loans, cars, games, movies, you name it. And than there comes a manager and says: “Fix here! Implement there!”. How to make job faster and easier? Answer - job should be simple. To be simple, to change things fast and easy, whole system should be built with simplicity in mind. KISS principle was applied to software engineering long time ago. Funny fact, in the book(Russian, 1991) where I met this abbreviation in first time, there were 256 pages.

All of those points of view led me to think of a good software, which makes all of the stakeholders satisfied. When software is profitable, reliable, easy-to-maintain. How this can happen, how software won’t shoot us with unstoppable bluescreens and error reports. How developers should work and how managers should let them do so in order to make quality product? What should be the principles behind the good software?

In my opinion - good software product build of good code. Most of work that called “Software Engineering” produces code. Code that is written by humans for humans. By accident, we have tools (computers) that can execute the instructions written in code. It’s actually doesn’t matter if it’s low-level assembly or functional languages. No software developer and manager shouldn’t forget that.

I’ve mapped all important aspects of what can be a code of good, quality software. I’d call it 3 Easy: easy to extend, easy to fix, easy to understand.

[Mindmap picture]

I do not claim the ownership of the ideas: these are principles described well. Most of them I learned from Uncle Bob, some from my studies, some from field work. I just want to give an overview with examples, what good software looks like, and what are the ways one can improve it.

Needless to say, that there is much more in good software. I did not covered marketing, community, support policies and other aspects of what we call good software. Meanwhile I’ll concentrate on this map, with series of posts, that will come in next few weeks.