Comment by jongjong | Hacker News Reader

Comment by jongjong | Hacker News Reader

I wasn't familiar with Andrew Kelly but he is spot on. It is a corporate conspiracy where the problem is manufactured and then later solved in a way which introduces yet more problems. It took me almost a decade years to figure this with high confidence.

This article is falling into a trap stating that 'requirement changes' are to blame for constant software rewrites. Good software architecture doesn't require full rewrites precisely because it anticipates requirement changes. That's the entire point of software architecture. Unfortunately, almost nobody has experienced good software architecture. Even among the very few who will encounter it, most of them won't recognize it because either they are not competent enough to appreciate it or they simply won't stay on the same project long enough to observe the benefits and flexibility of its architecture.

So yes, I think it definitely looks like a conspiracy. I've encountered many developers in my career who have had a tendency to over-engineer and create unnecessary complexity; they are often promoted within companies. Not only in agencies and consultancies (where the incentive to over-engineer is clear; more bugs = more repeat customers), but also in other large corporations and even non-profits.

There is a significant shortage of competence both on the developer side as they are unable to produce good architecture but also on the management side as they fail to recognize good architecture and accurately reward talent.

Most software developers and managers will outright deny the existence of 'good architecture'. They are such a large majority that their voices completely obscure the voices of the (guessing) 1% who know better. The voice of mediocre developers, propped up by short-term financial incentives, is much louder than the voice of excellent developers who pursue longer-term goals.

Unfortunately, if you're a top 1% software developer, the industry feels like Idiocracy, except for the crucial fact that, in Idiocracy, the idiots are just smart enough to identity who the intelligent people are.

There is a problem with the notion of 'good architecture', and that is people tend to have strongly different opinions on what a good architecture is.

Take a basic web application as an example. In the last 20 years, we went from n-tier, to generated frontend using some template framework, to rest server + js frontend, and recently generated frontends have become fashionable again.

Or for example enterprise architecture. We went from a bunch of monoliths with ad hoc interfaces, to service oriented architecture, to microservices, and now the trend goes to monoliths again.

I don't know if "good" architecture can be defined, but "consistent" architecture can. It's the lack of the latter I often see and that causes the most issues. Inconsistent architecture makes it very difficult to understand the overall system, which makes changes risky. There will always be mismatches between what our software does and what we want it to do -- either because we got it wrong the first time, or because conditions have changed. The most important attribute of software is it's ability to change, and for that consistency is key, as it makes it possible to actually understand the software. If you have variable names that don't correspond to the data they story, a hodge podge of different ways you are making network communications, state being stored, mutated, and accesses willy nilly... it's going to be a bad time. Have a vision of how it's all supposed to work, stick to it, and change deliberately as needed.

I think the problem is that when people think about 'good architecture' they're thinking 'silver bullet architecture.' There is no such thing. Different projects will require a different architecture. One project's good architecture may not be suitable for a different project. The architecture has to be adapted to the current and future requirements of the problem domain of the project.

There are some highly generic architectures like front end frameworks (e.g. VueJS, React, Angular) which are almost silver bullets but it's still a mistake to think of them in that way and they tend to be overused. But the fact that front end frameworks can handle an extremely broad set of front end requirements is a great example of how good architecture can handle requirement changes. It's unusual for someone to have to fork or swap out React due to front end requirement changes; it's usually an indication that React wasn't suitable for their use case to begin with. It would have to be a massive business pivot and you'd have to dump the entire codebase anyway if the requirement changes where that significant.

When discussing architecture in a broader sense, the front end is just one aspect. There have been many attempts to produce silver bullet full-stack frameworks (e.g. Meteor, SailsJS, DeepStream) and they are/were useful for a certain subset of projects, much smaller subset than what front end frameworks have achieved.

But there are many architectures that are heavily adapted to specific business domains and which are very far from silver bullets but which could be considered 'good architectures' nonetheless because they are good at handling domain-relevant requirement changes with minimal code changes necessary.

I just clarify managements priority before making decisions. It won't be framed as short vs. long-term but it's always clear. What are devs going to do, ignore the business realities and stomp off to create their masterpiece?

Reply on news.ycombinator.com