Comment by wellpast | Hacker News Reader

Comment by wellpast | Hacker News Reader

Parent Full thread

I'm not saying that it doesn't take time to build software and I'm not making a case for how to do management.

In my decade of experience on different teams and products, the main impedance to productivity has by far been to do with bad code and architectural choices. The justification is always "speed" but my point is that is wrong. It's not speed that is at fault, it's that most software engineers don't know how to properly engineer software -- they haven't been taught nor had the time to learn it. It's absolutely an issue of skill sets.

Yes, management and project estimation are other issues to work out. I'd say we're actually much further along on these fronts than we are on the technical skill sets front. That is, the skill set of building architecturally sound systems.*

* Note: I do believe there is a time trade off between features and feature flexibility -- but there is no time trade off necessary for achieving architectural soundness, again so long as the right (presently rare) skill sets are present.

> The justification is always "speed" but my point is that is wrong.

Not necessarily. Proper architecture takes time and planning and reasoning. If it didn't, we could make a program do it for us. There is absolutely a time tradeoff between coming up with the proper architecture for the application vs just using something that looked cool from a google project. The latter will always be faster at first, but not in the long term.

Describe good architectural choices?

That's a product of context is it not? And of course part of the context is the rest of the current architecture.

I think in the end the best architecture is that which is thought through from a contract-oriented approach, rather than a buzzword checklist.

There are three types of "good architectural choices"

The first: The ones that can be made after the original, bad ones. The second draft, which is an improvement in the first draft, in every field.

The second: His (or her) own. We all know there are developers out there who think they're the greatest thing to ever write code, and that everyone else's decisions are bad.

The third: The ones that really should have been made, in place of the ones that really shouldn't have been made. As in, "You wrote your own SQL parser using hardcoded strings and no grammar parsers?"

> As in, "You wrote your own SQL parser using hardcoded strings and no grammar parsers?"

(Shuffles away sheepishly)

There are some methodologies for this: http://en.wikipedia.org/wiki/Architecture_tradeoff_analysis_...

You've probably heard it as ones that lead to low-coupling and high-cohesion, which is correct. But in my experience this needs to be made more concrete -- many people can say these words, but couldn't tell you accurately to what degree a system was cohesive and uncoupled.

I am clueless about this, How do you learn to make good architectural choices?

By making a lot of shitty ones, realizing it afterwards, and gradually making less shitty ones until you rarely make shitty architectural choices.

100% agree. Though a lot of the churn here could be reduced with the right education and mentorship. There is a mathematics to good architectures -- a mathematics that can be taught. But currently the initiative of us are left to find the way ourselves. We need to find a way to formulate and teach this mathematics to the next generation/s so they can get there faster.

By not being insulated from the consequences of bad ones + iteration.

Good point. How many "rockstar" developers show up at Company X, build the initial versions of a product or architecture, then move on to the next company never to understand the longer term consequences of their choices?

Practice. As well as trying to notice when things work or don't (I have colleagues that see "firefighting" as a normal part of a running system. If something keeps needing attention, it is probably badly written or architected).

Linus said something along the lines of bad programmers worrying about the code, and good ones worrying about the data structures. I think there is truth in this, even though I develop Django database applications most of the time. If I find myself doing too much work at the application level, taking a step back I can usually see a better approach when I rearrange the database.

Reply on news.ycombinator.com