| Right. That second paragraph of yours, i.e.: >It often goes like this: Oh snap, we encountered a problem! Lets find a tool, framework, language that promises to solve a similar sounding problem. Now we have a problem with a layer of abstraction on top. Soon to be two problems. Lets find a tool, framework, language to solve both of them ... is absolutely real, I've actually seen in happen both in projects I was in, and heard or read about. This Rich Hickey video is somewhat relevant, IMO: Tech Video: Rich Hickey: Hammock-Driven Development: https://jugad2.blogspot.in/2016/03/tech-video-rich-hickey-ha... You have to watch it at least part way through to get some of the better points in it, although the whole thing is good. |
The difficulty I find is, identifying the moment to leave the hammock again in a startup enviroment. To what degree do you need to understand a problem before you take action. If you try to understand it 100%, you'll never get anything out there.
But I'm already very happy that I was able to convince the business side of the company of the approach in a brief talk about it and they now referrer to "the hammock" themselves :)