More is the goal
The majority of businesses that produce a software product choose to sell their wares by having the most features, or as I've most commonly heard it put; the 'richest feature set'. Businesses like this will court new clients only to find that winning that particular deal comes with a catch. Our software is only useful to our new prospect if we build a couple of new features to suit their business needs. This prospect is a big deal and these features are absolutely indispensable so we build them. If we're lucky, we win over the new client and get to pat each other on the back for a job well done. Everyone gets a Christmas bonus this year.
If you're thinking I'm about to follow up with a 'but', you're right. That may have been the right decision and I'm not saying that there is intrinsically anything bad about sweetening the deal to score a big contract. What I am saying though is, don't build something you can't maintain and more importantly, don't build something that doesn't make sense anymore, just to sign up someone new. You are trading in commodity terms and you cannot keep building features forever.
More is an addiction
Let's say you build the new features and score the new client. What then? Chances are you've just set a precedent. Any new client you approach is going to have more and more specific needs and to win the contracts, you are going to have to give in to them. This might sound dramatic but I have seen this happen too many times to be a coincidence.
Even when that isn't the case, we've trained our organisation into thinking what we have so far is not enough. You're possibly right too but you almost definitely won't find the answer by building even more software. You are heading down the road of stressed out developers, late nights, ropey releases and an endless cycle of death marches. Let me tell you, that is no fun at all!
Software development is an odd profession. If we were to compare the way we work to that of something more material like mechanical engineering, people would start to doubt our sanity.
I worked once with a team of fewer than 10 people, who updated and maintained a product that had more than 2 million lines of C++ built up over 15 years. 200,000+ lines of C++ each! Imagine the monstrosity you would have on your hands if you asked 10 mechanical engineers to keep building something for 15 years non-stop! Crazy right?
This is not, I'm afraid to say, a freak occurrence. It's particularly evident in 'the enterprise', B2B and most common of all, in finance. You do know your bank runs on COBOL don't you?
The nature of software is so intangible that we even trick ourselves into thinking we can build forever. Over the years, fads have come and gone claiming to be the thing that will save us from ourselves. Design patterns, SOLID, test driven development, behaviour driven development, continuous integration and deployment, domain driven design and most recently, microservices.
It's all good, don't get me wrong. It helps, but it doesn't change the fact that you can only maintain so much code. No matter what techniques you use to manage complexity, there is a limit and it doesn't matter how many people you hire.
Some organisations can get away with this for a while. If the market is rich and margins are high enough, nearly any new feature can send the balance sheet further into the black but there is more to software than sheer size.
After a while, as a software product grows, organisations are forced to hire more people and split the responsibilities of different components down into separate teams. Perhaps that's done by speciality (shudder) where you have the database team, the middleware team and the front end team. Perhaps you haven't fallen into that trap and you have product or feature teams where teams are cross-functional and can build and release their own little piece of the world, without any external influence.
Much better and kudos to you, that isn't easy. Either way, it's not enough if the goal is more. Eventually, change and complexity will sink the battleship.
More Developers < Change * Complexity
Let's assume two things. The more software you have, the more complex things get and change is more difficult when things are complex.
Knowing that change is practically constant, why would we choose to build something that is not designed to withstand it?
Now consider that software complexity does not correlate linearly with size; it grows exponentially. You might be able to hire three times as many developers when your product doubles in size but what about when it doubles again? And then again?
Even if you split it up into several pieces, it still all has to work together to create something whole. You cannot hire for that kind of growth and even if you could, it would destroy your margins. There are good patterns for handling huge amounts of complexity but they are very expensive to maintain and very difficult to master so you'll need to be paying top dollar for new staff. It's not a sustainable pattern of growth and eventually, it's just not worth building anything anymore.
So, you cannot solve the problem with more people. How then?
Skateboards are a truly simple invention. Four wheels, a board and (if you're luckier than I was as a kid) some brakes to help you stop. There's really little else to them and for good reason. There is no need for more.
What people in the skateboard industry strive for is the best. Better trucks, a more lightweight deck perhaps or smoother bearings. Everything in the design of a skateboard is about getting the most out of what a skateboard should be. They don't stick wings on the side and pretend it's an aeroplane. They don't stick four of them together, side by side and call it the family edition. Sure, you might get the occasional oddball that wants a jet powered one but you know what? Don't sell him one! It's not worth the hassle. There is a very specific job that a skateboard is supposed to do and each vendor will try to do that one thing better than the next.
We can learn a lot from that mentality. Our software should have a single clear reason to exist. Every effort we put into it should be in the pursuit of perfectly solving that problem with absolute clarity. You should not need to explain your software to people for the same reason hammers don't come with instruction manuals.
Understand the people who will be using your software. Do their job for a week and get to know all the little frustrations they have to deal with and productivity tips they use. Spend all your time making sure that what you are building works perfectly for them. Even if it doesn't get them 100% of the way there, do your bit right. Do it better than anyone else and remove everything that gets in the way.
If you have a product that has tens (maybe hundreds) of features, you need to start aggressively removing or relocating things. Especially the things that make your software more 'flexible'. When we say something is flexible, it's normally about trying to address different needs all at once but chances are, you have more than one product on your hands. That's a profitable place to find yourself!
Take a close look at how the features work with or against each other. Draw lines. Be ruthless when something doesn't pay its way because you are paying for it in every new line of code that is written. Every time a developer makes a change they have to keep all of this in their heads which slows them down. You can very quickly end up with something that does a whole bunch of disconnected things very poorly.
It's not an easy task for sure and it's tough to let go of or change something that once served you well but keep the skateboard example at the front of your mind.
Making great software is more about refinement than development.