Comment by unoti | Hacker News Reader

Comment by unoti | Hacker News Reader

There's a dangerous, contagious illness that developers of every generation get that causes them to worry about architecture and getting "street cred" even more than they worry about solving business problems. I've fallen victim to this myself, because street cred is important to me. But it's a trap.

An important meta-idea that encapsulates all of this is remember to solve your business problems as your first priority, and implement technology in service to that goal first and foremost.

It's far too easy to put various technology decisions in the driver seat, ahead of the business problems. This leads to all kinds of anti-patterns over the years. For example, I saw software development organizations destroy themselves trying to do 100% pure UML-first software using Oracle's Designer/2000 and Developer/2000 tools, because that was just the "right" way to do things. I've seen organizations destroy themselves in the morass of trying to do things with Enterprise Java Beans (EJB) because it was just the right way to do things. I've seen companies spend 10x more time getting their automated build processes and super duper full test coverage going than they spend trying to actually write software.

And I've seen companies navel-gaze over their processes and methodologies and buzzword compliance far more than they worry about meeting the needs of their customers. If you've ever worked for a company with a 15 year history of ironclad determination to use all of Microsoft's latest preferred data access methodologies, then you have first-hand knowledge of another example of this.

I'm not saying microservice architecture is a worthless fad, but I am saying that putting your business needs into the done-basket absolutely must be the first priority; never lose sight of it. I'm all for being wary of technical debt, but "technical debt" isn't nearly as dangerous as whatever you call that contagious illness that infects developers and makes them put architecture before business needs.

I agree with you, but the opposite of this is also horrible. I'm working for a company where they only focused on business needs, and the result is horrible. Terrible, unwieldy codebases, full of bugs, have no security at all. It's hard to develop features, it suffers from feature creep, have absolutely no test coverage at all.

It's important to find balance.

You're totally right: balance is the key. At least where you work there's a deployed product in production, though it is difficult and unwieldy. When you go the architecture astronaught direction, it's very easy to never make it into production at all!

Sounds like they only focused on short-term business needs.

Maintainability and security are definitely business needs, but they're long-term instead of short-term, so it's easy for new companies to underinvest in them.

I don't think that feature creep is a characteristic or symptom of a poorly-architected software system. It's just indicative of immature product/business management or conflicts of interest spanning the entire organization.

Ha, so true. Learned that lesson with Rational in my case :-)

Plus the compulsory EJB pain. I found it quite liberating to be able to just abandon EJBs once it became clear what a disaster they were without having to do do the Emperor's New Clothes bit.

I kind of share the scepticism about shiny new paradigms now, but one does have to be mindful not to inadvertently reject good new things because they're new.

It would help a lot if those developers spend some time in companies that don't produce software as their main business.

Where software is seen as a cost center and is actually developed 100% by contractors that fine-tune existing code bases across multiple years.

I guess there isn't better cure to those that tend to follow each fad that pops up.

I've worked in both types of environments and the companies where software is a cost center are just as bad if not worse than first class software companies with regard to latching onto a new technology or framework, half-assing an implementation, and then moving on to something else. The pattern seems to be to blame the framework rather than realizing the implementation was poor. "We made something and it sucked, must be the framework's fault!"

The thing to keep in mind is a minority of software developers are actually working on software with actual customers.

So when you don't have customers you get to anti-pattern and navel-gaze, because then, at least people are doing something.

It's important to solve problems, but if you want to win at this startup game, how you solve those problems can make or break you.

In most cases there others solving the same problem. If you are the team bringing a better solution to market faster, with better design, higher quality, less maintenance, lower infrastructure costs, fewer developers - you win easier and earlier. But, that takes some dabbling and experimenting.

In the end, it's really about working with high quality people. A team of focused, pragmatic, informed, and disciplined people can take the right new tool and become an order of magnitude better. And, they can take the wrong new tool and know when to shelve it quickly.

The winners in this game aren't writing COBOL against mainframes - even though that would probably yield a sufficient solution eventually.

Very well said.

A clean data model, one aligned with business needs, and sensitive to the nature of machines, makes the best architecture.

Far too many decisions are based on what is trendy and fashionable rather than what is right for the domain.

> more than they worry about solving business problems.

That's why companies implement Agile. It's all about "solving business problems". No architecture, no design, no documentation (merely 'user stories'). Dump and re-write instead of maintain. All your problems solved!

Reply on news.ycombinator.com