undefined | Better HN

0 pointscarlmr6y ago0 comments

I'd also be interested. Some drivers of complexity I would think of:

* Using many of the GoF/OOP patterns, because you may need extensibility at some point. Basically YAGNI.

* Complex, hard to mentally map, build systems (e.g. CMake).

* Designing for purity over simplicity (I'm actually big on FP, here I'm thinking of the Haskell crowd which IMHO sometimes overdoes it).

* Writing a complex architecture without prototyping. Often your prototype will tell you what you need. If you start architecting too much beforehand then you often waste time on some details that don't matter, and even worse, afterwards you try to force it into your architecture which doesn't actually fit the problem. The beauty of software is that it's easy to change things. Architecture on buildings is different because you need to make sure that you're not building the wrong thing. In software building the wrong thing can give you the right insights and still be faster than planning for every eventuality.

0 comments

2 comments · 2 top-level

doublement6y ago

> Writing a complex architecture without prototyping. Often your prototype will tell you what you need.

One million times yes. In my experience using a prototype as an input to a specification works much better than the other way around.

> Complex, hard to mentally map, build systems (e.g. CMake).

Also yes. It's almost to the point where one has to understand every detail of how CMake works to get it to do one (1) specific thing you need in your build process.

heisenbit6y ago

* Splitting requirements documents into user stories and then evolving the document further. This practice can be improved upon by adding redundancy with attaching the document to user stories and enterprise wiki. Further optimization can get to the org to CMMI level 5 but requires investment in diversity of the most critical requirements in other locations and protection of these assets from being linked.

j / k navigate · click thread line to collapse