Comment by CurleighBraces | Hacker News Reader

Comment by CurleighBraces | Hacker News Reader

Parent Full thread

Thanks for taking the time to reply, please take my response as earnest attempts to better myself :)

So, I think I didn't elaborate on the process enough to get the answers I was looking for. Here's what happened.

1. I would uncover a requirement from the business 2. The conceptual design would be written, high level understanding of the feature etc that was trying to be written 3. Conceptual design would be signed off 4. Logical design would take place ( I think this is basically everything from the Constraints section down in your model ) 5. Logical design would get reviewed and signed off.

Now technically everyone could and was encouraged to sign off the logical design, but in reality maybe one other person in the team would, I don't really know the reasons why.

Then implementation start, this was usually NOT me but another team member tasked with the design, and this is where the process really started to fall down with the onus being put squarely back on me as to why the design didn't work :)

I also actually tried the other approach, implement as much as possible ( because AI fast ) and then reverse engineer the design, but then that very much felt like, what the hell is the point now? I might as well just use the standard code review process.

Does that make sense? Sound familiar?

It's hard to say without knowing what things are like at the company/team you work for, but I can say the things you're describing sound unusual to me.

Most significantly, it's strange for the person writing the design doc not to be the person implementing the code. This is asking for trouble because there's a principal-agent problem[0], and also there's bound to be signal lost in the handoff between designer and implementer. It's not so unusual for the design doc author to work with a team on implementation, but they'd still be actively involved in implementation, which sounds different from what you're describing.

I've also never heard of this separation between a conceptual design doc and a logical design doc. I've been on teams where the product manager writes a UX-focused spec, and then the dev writes a technical-focused spec, but I've never heard of a conceptual vs. logical spec.

Does the org have a strong engineering culture in other ways? Like automated tests, automated deploys, automated monitoring/alerting, useful code reviews? Because the easiest answer is that you're in an org with poor software engineering practices, or at least weak documentation culture, and the design review process you're experiencing is there for historical or political reasons rather than engineering reasons.

[0] https://en.wikipedia.org/wiki/Principal%E2%80%93agent_proble...

Well, there's a fascinating insight, most orgs I've ever worked for have had the documentation produced by someone else and them implemented by the developer.

For instance the enterprise architect/solutions architect ( or whatever job title is fashionable at the time ) would write the document and then send it over to the development team and obviously that wouldn't work.

I actually adopted the conceptual/logical design from two ex Hewlett Packard engineers/architects who introduced the idea to me, probably some twenty years ago now!

Yep we're strong in many other ways, but finding the transition to AI challenging :)

Reviews have somewhat turned into, I send you the output from my AI agent of choice, and you tell your AI agent of choice to fix it :)

Thanks again for the time taken to reply :) It is appreciated.

Reply on news.ycombinator.com