Hacker News Reader

Comment by kgeist | Hacker News Reader

>Most engineering teams have some sort of approval process, often called a technical review, which is usually reserved for the later stages in a project. The problem with late-stage technical reviews is that when they happen too late, like when a direction or design has already been built out, they can lead to launch-blocking feedback.

At our company, technical design reviews happen before any work on a feature begins. I thought it's the case everywhere. Why would anyone review a design/ architecture after it's already been built?

It's also never just an approval here, most devs usually have something to say, and a technical design can be completely rewritten/rethought.

Also we don't formalize it too much, it's just a few folks in an informal setting discussing diagrams for 1-2 hours. In the end we decide if it looks good enough after all the tweaks, or we need another session.

View on HN

I used to develop apps and websites in the pharma space. It’s a heavily regulated field that requires submitting wireframes and functional specs to the FDA for compliance purposes.

This ended up creating a huge waterfall before any code was written and usually locked in the requirements - but the devs and designers had their guardrails and specifications so they could both go off on their merry way for a couple of months.

I was surprised how alien this process was when getting into start up’s but there’s obviously a middle ground of light wireframes and review before you find out all of the horrible details that weren’t covered by the individual teams.

A lot of "agile" (in quotes because a lot of them are not meaningfully agile) shops have used "agile" as an excuse to ditch a whole lot of the upfront design and review process.

A substantial number of them subsequently end up "inventing" these processes all over.

Agree that serious review too late is very annoying for all involved. Reviewers are unhappy they have to reject, implementers are unhappy to have their work rejected, and product folk are unhappy that their feature is delayed.

There’s a happy medium, when necessary, where building a light proof of concept before engaging in design review unearths unknowns or other such things that you can’t get from a purely theoretical design session.

Just trying to complement what you said, not refute it :)

There's nothing more permanent in this universe than a quick hacky proof of concept that was never intended for production use.

especially when it was by your boss the owner while they were on a plane flight. I got a few of these over the years. One was the vacation time thing. It was 80% done. Was written originally in rails in like 4 hours (flight from LA to STL). I think we spent about 4 engineer years before we worked out all of the edge cases. Thanks for all of the paid work Steve E!

> Why would anyone review a design/ architecture after it's already been built?

Many reasons. They might not have known it was being built, or they might disapprove of how it's turned out compared to initial presentation, or there might have been a shift in priority making the current project not a good fit.

Or in my world, "We skated around the security/risk review by claiming it is a low-risk application [no PII data, not customer facing, only a PoC, etc], but now we're doing all of those things. The auditors caught on to us and are saying we have to have a review by security. It's already in production so we're not changing a thing. You guys figure out how to make the auditors happy since we won't be held accountable.". Good times.

A special case of, "I got all the glory for doing the easy part, you get to take the hard part."

Feel free to drop your company name here with pride, because that feels like a breath of fresh air.

I second that they should be proud of this, it is the way it should be done. However in my experience it is not that rare. If you work around capable engineers such process always happens by itself, IME, because they all want ideas and suggestions as early as possible. It results in a better product and more maintainable system if peers share their experience, and 1-2 hour initial meetings are great for this. As are brainstorming sessions for overcoming challenges along the way.

Design review 'should' be a process that overlaps with the technical review. In other meanings, not isolated from the org. And that overlap 'should' overlap multiple times with the technical review , not just once, at the end nor just at the beginning (shift in priorities, new team new people, etc).

As said elsewhere, a lot can change between initial design and release so having multiple design/technical reviews 'should' be standard. But inherent in the design/technical reviews is time, resources, and culture which many many companies lack and/or don't include into budgets/project estimates/etc and/or a culture of development practices.

A shop might have a design team and a bunch of devs with probably a single person who actually understands how things are connected. Limited time and resources precludes a thorough design/technical review process But also consider that many companies willfully avoid 'wasting' developer time, setting up meetings, etc.

Turns out figma's design culture inspired change in their engineering culture to overlap their processes in a continuous development manner.

A lot can change between initial design and release. It's useful to consider the product as built and not only as first envisioned. Typically the design review focuses on the overall approach and placement (new services, use / non-use of existing platforms) while the launch-gating review focuses on reliability.

Reply on news.ycombinator.com