First do one thing well. A simple rule, sure, but profound. Every disaster of a software project likely ignored this simple truism. By focusing on doing one thing well from the start, you’ll increase your confidence, your client’s confidence in your team, and your likelihood of success.
In general, business owners want software developed because they are in search of revenue. Maybe that revenue comes in the form of added internal efficiencies, or maybe it comes in the form of new customers. The fact of the matter is that the needs of the technology will continue to evolve. Your perfect software system from last year surely could use some improvement, still today.
Do One Thing and Do It Well
The rare case that this appears to be invalid is Unix tools. Most of these have been around since the 70s, like wget, sed, awk, curl, less, cat, etc. These tools have sustained their viability as long as they have due to their simple purpose and their persistence of reliability. These comparatively ancient tools should give us some insight into how to build software to last.
As a software team, the goal must always be to deliver working software. It can’t take six months. Every day when you sit down to write some code, by the end of that day, you must have some portion of some working software. Hard stop.
Six months of work won’t ever fit into a single coding session; however, if you don’t have a single portion of a functioning software, I mean what did you spend your time doing?
Sitting at the computer, physically writing code is only a fraction of the time. The other portion is called planning — and, it may be quite involved. Spending time with your colleagues to digest system requirements is fundamentally valuable time to determine your best approach for building a software system.
Remember, the goal of the system is to generate revenue for the business in some way.
By the time your plans are in place, you and your team must take the time to break down the work into small chunks. By sizing work appropriatley, you’ll increase your team’s ability to deliver. If each task can’t be completed in less than a day, the tasks aren’t small enough to be worked on.
In our experience, this is by far the most effective and reliable way to ensure that all time spent coding is productive and value producing. As long as you’re producing value on a daily basis, generally, client relationships should be easily maintainable, and there shouldn’t be much conflict.
Never manage to a failing goal.
It’s just that simple. As soon as you take $250,000 for a six-month project and plan to deliver the software at the end of six months, without frequent successful value delivery within the first week of adding coders to the project, red flags ought to be going off.
Setting up the underlying infrastructure to support value delivery
Getting from scratch to a fully operational CI/CD system capable of scaling up to hundreds of thousands of users will take months: It necessarily requires a feedback loop to improve. Before you go asking your contractors to build you this sort of ecosystem reliability, be sure to ask yourself: “Do I have hundreds of thousands of users? How many users do I have right now? How many users will I hope to have in a best-case scenario, six months from now?”
Any improvement that is made to a system away from the system’s constraints is an illusion.
If the best case scenario is you’ll have 100 users, then you should forget about your non-existent scaling issues. You can solve your scaling problem when you have a scaling problem. Paul Graham says to Do Things that Don’t Scale. If you need bank-level security, that’s great. Does your software do anything yet?
Bank level security is not a feature if you don’t have working software. Start at square one, not square nine. Once you have a fully functioning system, then you can start to work through security and scaling. You don’t even know if the software team was able to build what you wanted yet. Would you rather have bank-level security and a non-functioning system, or would you prefer a functioning software system that needs to have its security upgraded before launch? Trust us; you want the later.
So, if as a client you can’t understand that, then I’m sorry, I don’t know how to work with you. We won’t be successful, and although we’ll make some money on the project, it is a waste of everyone’s time.
Time is the only thing you can’t buy.