> TL;DR Software Engineers see world in patterns, they look for common denominators, not accepting the fact that something may be an one & only instance. That's why we sometimes end up building frameworks for single problem occurrences ("we'll gonna need it in future&...
> TL;DR Decomposition of functional requirements into atomic User Stories doesn't mean that activity of elaborate design is redundant - there's always a need of shaping the system's conceptual model: usually at various levels of detail (for different reader categories) & taking into...
> TL;DR Getting end-users' and sponsors' feedback is crucial if you really want to build (/enhance) a good product, but it doesn't mean that you can let them "think with solutions" and mindlessly introduce suggested changes yourself. Business insights ought to be reforged...
I strongly believe in emerging design & evolutionary architecture. I've seen too much in my life ;> to believe in up-front design & beautiful pictures turning miraculously into flawless, working systems. I'll save you detailed reasoning as I've written about that on several occasions...
If it comes to decide between "build or buy", it’s usually a hard choice to make. Even if you pick the ready "off-the-shelf" product, it usually needs a lot of polishing to make it work. You can call yourself lucky if such adjustments can be...
