What makes software good

There are also several other aspects, not directly related to code but to the testing, deployment and runtime, that are not mentioned here.

They are already covered in some other checklists, so I decided to skip them here. Usually, they are less generic and depend more on the kind of the application, environment and so on.

Knowing what makes a good software should help us to come up with ways to achieve it. Depending on the platform, language or frameworks we decide to use it may require different approach or tools, but some of the things should be common regardless of those. If you name your function or endpoint updateName , make sure it does exactly that, and nothing else.

If you're using statically typed language which you should do! Take this method as an example:. If you look at the signature, you could expect that it gets a Person and a Name and returns a new version of provided Person with updated Name. As you can clearly see it doesn't fulfil the promise.

It actually mutates the input value, so it clearly has an unexpected side effect. Things are a bit better now. It still has a side effect, but at least that's what you can expect from a signature. It's good to know the important things without a need to dig into the details. When I first open some project the most important thing I want to know is what it's supposed to do. How things are solved is much less important, at least on the technical level. I want to know what are the key domain objects the software is dealing with.

On the level of APIs e. On the level of data structures, I want to know what is the root object and what it consists of. I don't care where are the services, proxies or interfaces. Group things by domains, not by technical details. Use pattern names with consideration, and if possible avoid them. I want to know the entry point and steps that are required to solve given problem, not which pattern did you learn about yesterday.

When it comes to dependencies, keep the structure flat. I rather read longer method than dig through multiple classes to figure out what is going on. It's OK to hide some less relevant details, but be explicit with the important actions. You and your team will be thankful for that, especially when coming back to the code after some time.

Probably most of the functions require some dependencies to do the work they're supposed to do. Whenever it's possible, prefer explicit parameters over implicit ones like dependencies injected by the container. It makes signatures more elaborate, and while it may seem to be extra overhead at the beginning, it isn't actually that hard.

If your language supports partial application then it's probably not a deal at all. Making function dependencies explicit enables composability on the higher level than it is possible with implicit ones. You're no longer tied to components that need to be designed to work together usually via interfaces - you can mix and match functions as it makes sense for you.

Any function signature becomes its interface, and lamdas become adapters whenever required. Welcome to the world of programming LEGO. And the outcome? You can say more about your code at the first glance, without a need to jump between places. Reasoning about the code will be much easier. This is a tricky one. You should write code for people to understand it, and it sometimes feels like you should start using what you've learned in the literature classes. And while some of the hints from the literature may be helpful, others may be really bad ideas.

Take the synonyms as an example. When writing prose you are supposed to use them to not repeat yourself, so that the outcome will be more artistic and less monotone. But when writing code, being boring and repetitive is actually a very good idea. When you'll decide to call the customer number, well, CustomerNumber , don't call it ClientNumber or CustomerId in other places. Be consistently boring with the naming.

That's especially important when you're within one domain, but even across domains, it's good to keep the names consistent - unless they are actually different values. That will save you a lot of memory resources when reasoning about the code and will help to reduce the number of bugs caused by confusion. Even when you're dealing with many values of the same property within one scope, make sure to be consistent, e.

It's usually most effective approach to fix an issue before it develops into some serious problem. The less resource a piece of software uses, the better. Processor, memory and disk space usage should be minimized. A system that can perform the required functions stably is important. Failures should be as rare as possible. Security should be taken into account. Our software should let attackers access unauthorized resources. The accuracy of its outputs is good. This measures if the software outputs the right results for users.

The ease in which an existing system can be changed is important. The easier that we can make changes, the better. The more reusable parts that a piece of software has, the better. Easy to read code is easy to change code. If we understand them faster, then we can make changes faster and in a less error-prone way. Making our software system testable is critical.

The ability for us to understand our system in a global view or at the detailed code level is important. Easier to understand systems are more coherent. Setting objectives for maintaining software quality is a good way to increase quality.

It gives us something to work towards. Quality assurance is always important. Without it, users will see the defects since no one is catching them. It makes us more stressed and our reputation is worsened because of it. Sign Up. Thanks for signing up.

Stay tuned for updates from the Forrester blogs. European Predictions Visit our resource hub to discover the key trends impacting European businesses in Explore Now.

Jacob Morgan 1 day ago. David Truog 2 days ago. To create an effective chatbot you need to master conversation design, a new discipline for experiences based on conversational AI.