Software Design Review (2009) | Hacker News Reader

Software Design Review (2009)

philip.greenspun.com

33 pointsOJFord13 comments

Wow, even though I already had over a decade experience under my belt at the time this was written, it still feels hopelessly archaic. Granted, the problems outlined were (and probably still are) real at certain types of companies, but the proposed solution is so wrong-headed.

The only honest takeaway here is that if you want to write software as a large company, then you need technical management. The foundation of good engineering work is competence and trust; in other words, the team must have the chops and there must a trusting direction with management (both ways). All this faff about documenting every last detail and have it reviewed by "experts" for $100/hr is the most ridiculous kind of bunk. There is a time and place for technical documentation and its review, but not as a solution to a fundamentally broken team.

> However, it is outside the realm of acceptable discourse for a manager to say "this is terrible work."

Why? And how is it possible for Americans to build anything while having that kind of a constraint?

Because it's not constructive.

How about "This is a terrible work because of ..." - is this a not constructive way as well?

IMO everyone produces some terrible work early in their careers. It is part of the learning/growth process. I wouldn't want to work for a manager who told me "This is terrible", nor would I dream of saying that to an employee of mine, it would unnecessarily break their spirit. I think that would cultivate the type of environment where people are afraid to voice their opinion for fear of being embarrassed, etc.

Because it’s a waste of time to say it. It’s entirely emotional and subjective and not helpful.

Now, instead of listening to you and giving you a response, this person is in some kind of an internal spiral. They will either push back, equally emotionally, or they’ll shut down. It’s a rare bird who will take that kind of feedback in stride. Even if you find one of those, you’ve most likely lost personal capita with them in the process.

Stick to the facts and learn to manage your emotional feedback. I came up in these kind of “blunt” cultures, and it was a terrible waste of time and energy, and it took a long time to unlearn these patterns of behavior.

"Terrible" is often emotionally laden and unprofessional. Better to simply specify the ways in which it fails to meet general standards or the stated requirements.

"this is terrible work" is a childish outburst, not a meaningful criticism that could be used to improve anything. The people engaging in that kind of behavior are the ones who sabotage building things.

It's always hard to balance delivering fast vs delivering quality software. I've been involved into multiple similar reviews were I'm coming as an outsider and assess existing platforms. Both what people will typically call "legacy" but also "modern" (read microservices) ones. Without a clear governance and consistency any of the approaches will end up with similar issues: performance, scalability, hard to extend/maintain, excessive use of tooling (there was one platform that kept all logs in a log aggregating tool, but didn't have any way to get the raw data). You can be fast and consistent/have a clear vision. No need to get it to production "no matter what".

In some sense, many "developers" are also cheaters, or thieves.

Because a working product is not actually the expected product.

It must be based on some specialized benmarch and criterias.

It's a lesson for business people or shareholders to learn.

Example: To fix N+1 issue in RoR application is not simple. Cheaters won't spend their efforts to fix it to release.

> Cheaters won't spend their efforts to fix it to release

What reasons would developers have to 'cheat', as you call it? If they are experienced enough to recognize something like problematic N+1 queries, why wouldn't they rewrite them, regardless of the effort? Further, what reason would they have to write them in the first place, if they know better?

Business people don't know N+1 query is the issue.

Normally they only care if a feature is working or not.

About performance, it's upon the developer to fix it or not.

Yes, those are broadly true generalizations, but they don't answer my question.

> it's upon the developer to fix it or not.

But why wouldn't the developer fix it? What incentives do they have for leaving a known problem unaddressed?

Reply on news.ycombinator.com