Oh boy, I’ve seen it to often...
« So let’s start with the UI and where things are gonna be »
« But shouldn’t we be sure that the content fits the demand first »
« No. You know customers, if they don’t see something very visual, they think we are not working, so start with UI »<p>And in the end, you find that not only you had to twist your server code to fit the « visual needs », but you still changed the UI so many times that your project explodes the deadlines.<p>I have a name for project like that, the name of a client I had from back in the days when I was younger.<p>Now, I try to run away from that kind of projects (not always succeeding, in 2015 I joined a project like that and loose a year and a half producing jquery shit)
When I start at step 1 with the skate board, it looks like the first part of the cartoon... 1) Build one wheel, 2) Build two wheels, 3) build connections between wheels, etc...<p>(<a href="https://cdn-images-1.medium.com/max/1600/1*tcNs35GceDxSGxAaFh-lSA.jpeg" rel="nofollow">https://cdn-images-1.medium.com/max/1600/1*tcNs35GceDxSGxAaF...</a>)<p>I don't know how this guys codes, but nothing happens all at once. -.- (am I programming wrong? Where's the magic "write code for me" button I've not found?)<p>I think he's trying to describe "minimum viable product". (my new favorite buzz phrase, already used it with a client, and it works. No disagreements there.)
Pardon me, if I'm wrong, but doesn't the article argue against its initial argument ("Code less, think more")?<p>In my understanding an incremental "delivery" plan, like the one illustrated by the comic involves actually more coding and rewriting of things on its way to the final goal. The author admits this even in "Incremental Delivery can actually take more time to finish the whole thing!".<p>Also, I do not get why the clients smiley 3 in the upper row is so angry about the almost convertible looking like chassis if the requirements changed to convertible and the client's smiley 5 in the bottom row is super happy about the chassis with an added windshield.<p>My key takeaway is: Think more about how to built a useful part of a split-up big project, instead of how to build a big project and increment throughout development. And: don't aim for a starship, if you actually want a glider.
I've seen that comic a lot (or perhaps variants of it), but I find it hard to relate to, since all the examples I see demonstrate almost the opposite. The organic bottom path is 5 steps instead of 4, but they're also much bigger steps. If you know what you want to build and how to build it, it's drastically less work to just build it from the start.<p>Tesla went from founding to producing the Roadster in less than 5 years. Honda took decades just to move from motorcycles to cars. There have been several electric motorcycle companies in recent years, and none has been terribly successful so far.<p>I think the organic path makes sense when each step on it is a simpler profitable company, not just a simpler product.
Reading this, I feel like many "continuous delivery" frameworks miss the mark. You don't need to have a powerful, complex server set up just for expediting as-fast-as-robotically-possible releases to your customers, because that's burden and investment you don't need to start with. All you need to do is make small version changes and do as little as possible to make it live.
The car example is fun but very unrealistic. The up front investment to build something big (car, house, PhotoShop, AutoCAD) requires up front planning. It's difficult to get right but that doesn't mean it's always bad or unnecessary.<p>There's a sweet spot for CI and other incremental delivery processes. Websites and modern apps are a great fit but there's lots of SW development projects that can benefit from good old fashioned planning.
>Last time I wrote about Continuous Integration: A Merge Story. The post describes how a 6 months project failed because it didn't implement the principles of Continuous Integration.<p>I stopped at the first paragraph. Plenty of software companies for decades wrote successful software without using continuous integration, which makes the opening statement questionable. Does CI help automate annoying and risky grunt work? Absolutely. Will your project automatically fail if you don't use it? Absolutely not.