It appears that way short term, but long term, having a bad codebase can retard a company's growth through lack of scalability and maintainability (read easily add/remove/change features). Companies spend a hell of a lot of money for growth. If they don't know how to manage software development, then the software will nullify all that cost spend on growing, because the system can't handle it.
I am truly amazed at how bad many US businesses are at managing their software systems. It's as if they are considered an afterthought rather than the department on which every other department depends. It's simply old fashioned thinking. CEOs are typically older, and the current crop were trained before computers really proliferated business.
> It's simply old fashioned thinking. CEOs are typically older, and the current crop were trained before computers really proliferated business.
It's really not this at all. It's not a generational thing and it's not an old-fashioned thing. The ultimate rule of workplace dynamics is whether your position is seen as a cost center or a profit center. In software, most often your job is treated as a cost center.
My company is the third tech company from a repeat founder who is younger than me (he's 29) and was previously acquired by a huge tech company. He absolutely sees the work as I do as commodity and doesn't understand what I do or what its value is. I've built rock-solid, scalable systems, envisioned and built tools that will bring us more (and better clients) and saved my company hundreds of thousands of dollars in a year. If I don't fight for the projects I want to do and push back against bad ideas, I get tasked with essentially pointless "tech janitor" work.
I've encountered non-technical executives well into their 60s who deeply understand the value of tech. You just have to find people to work for that aren't idiots.
> It appears that way short term, but long term, having a bad codebase can retard a company's growth through lack of scalability and maintainability
Still, it depends on the specifics. Many, many projects get redone/canceled/completely respecified after first contact with market / customer. Many are also canceled for reasons that are independent of the progress speed. For all these projects, speed-to-market has value, and long-term-maintainability has absolutely zero.
The horror arrives when, in a successful project, you realize that you are going to live with the hastily, horribly, developed project for some time to come. But these might be the exceptions - depending on how you count, some stats claim 80% of software projects get cancelled before completion (Have no idea how they define that)
I agree, the devil is in the details, but intentionally writing hastily thought out software is rarely a good option. Even for a POC or MVP, code is expected to be churned out fast, only to be heavily refactored or rewritten once proven successful, but that never seems to get budgeted and people end up building on top of that.
I always go back to the KISS, DRY and YAGNI principles. They not only save overall development time, even in the short term, but they typically lead to maintainable, scalable, and expandable software.
> I am truly amazed at how bad many US businesses are at managing their software systems.
I'm guessing you'd be equally amazed at how many people are embracing rigorous software engineering principles, and not ever reaching the point of getting a viable business off the ground.
So, perhaps the best way to go about it is to sell "prototypes" at first, and then when the business catches on, hire some CS people to manage the mess.
>I'm guessing you'd be equally amazed at how many people are embracing rigorous software engineering principles, and not ever reaching the point of getting a viable business off the ground.
Yes. It's very strange the process business impose on software teams when the business is really just stabbing in the dark. I think it's because they don't realize software development is really an art rather than a science.
>So, perhaps the best way to go about it is to sell "prototypes" at first
Yes, I think that is a good method. Really everything is a prototype from a mile high view. Word 2.0 from today's view is certainly a prototype. A sellable running prototype.
In my experience, business process means almost nothing in software development, it's the people. Good people are expensive but you will most likely fail without at least a few of them.
What I've learned is that most companies that are really not in it for the long haul and just want to exit will pass the technical debt off to a much larger company that can supposedly shoulder the burdens of technical debt. The M&A process at large companies really don't look at how sustainable the codebase or infrastructure is - they only look at regulatory liabilities like super bad security practices and that's only if you're in a strongly regulated industry.
So, the current incentives mean "bang out code super fast, get rich, and someone else will figure it out." This attitude is a huge part of how so many bad acquisitions seem to be happening for the past maybe 10 years by various large technology companies as the VC owned market has grown so much compared to IPOed companies. Companies like HP, Yahoo, Dell, IBM, etc. are all in varying states of decomposition. Yes, the major tech giants are doing just fine but their M&A approach seems to be substantially different and they try to take on smaller companies and grow them before they have too much inertia keeping them from being adaptable.
Enterprise integration is a really hard problem that at this point is almost entirely impossible to approach algorithmically or from a technical solution. Sadly, you're not about to impress anyone in a technical interview how you managed to get a company's horrendous codebase to cleanly integrate with a big behemoth ESB - that doesn't signal anything about your ability to code or work with others evidently. Worse for the acquirer, the refactoring and painstaking tasks of integration are usually done with an army of hired guns that are very expensive and the work is non-scalable due to being entirely business-specific. In the process leading to the acquisition, many execs burn through their technical staff or their cap tables are messy and they wind up giving little to the engineers. The resentment alone causes a mass exodus and those most knowledgeable about the codebase depart while the execs have solidly backed their exits legally to get plenty of compensation while marking off a successful exit for future investors to look at as a positive signal for investment. Golden parachutes and different kinds of leashes hardly help until the next company trying to do the very same thing comes calling renewing the cycle of rewarding throwaway technology and IP. Then again in enterprise, 90% of what's being bought are patents and customer bases that have high switching costs with some vague notion of "alignment" with some marketecture diagram made by someone that hasn't touched or seen anything besides a sales demo in decades, so perhaps perception and suspension of disbelief is all that matters.
In many respects, I view a lot of codebases out there as evidence of the tragedy of the commons - it is a side effect of ignored externalities by every actor. There are so few incentives put into the market to make the cost of software maintenance lower it's mind-boggling how technology companies can stay in business.
Thanks, that was an insightful reply. It's like when the banks pushed off mortgage risk to the public market before the great recession. Companies accrue massive technical debt (risk), but push it on the buying company who either isn't competent enough to DD the software, or simply doesn't care. In the end, someone has to pay for that negligence, but it's like playing hot potato or musical chairs.
In hindsight, I think that the M&A process of companies is actually correctly aligned with their true costs. For most big enterprise "tech" companies, their biggest operating expenses aren't technologists at all - it's sales commissions (stock options are as a rule terrible for engineers at every old hat tech company). So instead of paying $4.2MM to acquire a customer or two, you acquire a tech start-up that already has the customers and the product people are mostly cogs - the technology itself is an afterthought. For the few companies where engineers are compensated like the sales folks in enterprise tech (about $300k+ up) it is now cheaper to acquire technology faster than to pay for engineers in-house to develop it - market fit is not a big deal because the growth model is easy to scale with minimal sales staffing costs (a luxury in business through and through).
As for the question of whom pays for the negligence of M&As in the tech sector, it's mostly shareholders rather than the US taxpayer at least. With HP, IBM, and others laying off employees faster than Macy's and Sears the negative outlook is baked into Wall Street's prognosis of increasingly lowered expectations.
Myself, I just wish I could slightly tweak index funds to exclude specific tech companies I know are complete garbage long-term (similar to cable unbundling trends). I know Vanguard probably won't do it for me but maybe the transaction costs will be low enough that excluding the junk companies that literally only exist on an index for being big and being a market leader is a net win.
I am truly amazed at how bad many US businesses are at managing their software systems. It's as if they are considered an afterthought rather than the department on which every other department depends. It's simply old fashioned thinking. CEOs are typically older, and the current crop were trained before computers really proliferated business.