Regardless of scope, time or budget, software needs to be built (and delivered). So what happens when you have to compromise?
Necessary drawbacks are a common concept. We understand that a product can't be good, durable and cheap at the same time. When faced with the choice, we have to "pick two".
In software projects that are three aspects that compete for the resources available: Cost, Time and Efficacy. However, this view on software is very shallow. Any project's needs nowadays involve security, stability, user experience, compatibility and the list goes on. When we add those into the mix, "picking two" is not really an option.
When priorities are defined by the needs of the client (When treating sensitive data, security is a must; When creating the new hot app, user experience is the focus; etc) figuring out where to spend more time and budget on is an easy task.
However, for most projects, there seems to be an even mix of importance between all the areas. So, where do you invest more time? How do you split your efforts?
Well, let me give you an answer. Not the answer. Just one possible answer.
Invest into a strong architecture and focus on developer's ergonomics.
Your software will be developed by human beings. And the truth is that we all make mistakes when left alone to do so. So, how do you prevent errors, flaws, leaks, etc?
Easy! Don't let them happen.
While this may all sound silly to you now, I guarantee that this will all make sense when I'm done.
Software architecture is incredibly important for all I'm about to talk. From how robust the software is, to how easy it is to extend. All aspects relevant to the developers are laid out by the software architecture.
Plan your software like you'd plan a battle. Divide responsibilities and conquer the problems. Your data and your operations should be separated. If you want to achieve this, make so all the data extraction and capture happens in one place and the data manipulation happens in another.
You need to query a database and show a chart on the application? Try thinking on small steps: Extract from the database, process the data into a chart-able format, create said chart.
If you separate your application in an architectural standpoint you will be able to come up with a library of utilities and functions rather than cramped files full of local-only procedures. And as a bonus, if you do it right, you don't have to rewrite anything when your data changes, just plug-and-play!
If you are thinking that that's awesome, let me push that point even further. Remember all those separate, unitary functions you are making? Guess how easy it is to write unit tests for them?
When you stop writing an unit test that "queries a database and shows a chart on the application" and you start making tests for "query a database", "turn data into chart-format", "show chart in the front-end" your tests not only become way simpler, they are also way better.
You can not only achieve stable and secure software with properly separated responsibilities, you can also make your development life much much easier and safe.
Don't set yourself up for failure. Invest more time and budget into making a robust system. Making a good foundation is hard, but you will not regret it after you start stacking functionality on top of it. It's important to deliver. And deliver fast. So invest in your tools and let your developers be as efficient as they can be.
Don't waste your time with weird tangled code-bases. In 10 years you will thank me when you don't have to hire an Senior developer just to read your software. Make your life simpler now and in the future.
Don't believe me? Want to see more? Check this talk out: