6 ms·

Code Less, Think More… Incrementally

115 points by treyhuffine 9y ago

JeanMarcS 9y ago
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 » 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. I have a name for project like that, the name of a client I had from back in the days when I was younger. 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)
- mrarjen 9y ago
  This sounds like a real case of the client knows everything better, and only hired you so they could let you know they are better at your job. If only we could get those years of wasted development back.
- treyhuffine 9y ago
  That scene is too familiar. Trying to get a client to understand incremental delivery is probably more difficult than enforcing the practice on a team.
- Terr_ 9y ago
  I've observed something a little bit like this on some long-running internal business tools, where the "GUI-first development" approach also causes problems. Your data model ends up resembling the entry-forms and wizard-steps proposed by managers, rather than capturing the underlying ideas of the bounded-context. Since having it look right is so important, you also get a lot of business logic which lives closer to the GUI than it should. This makes it difficult to automate things because certain rules are soft-enforced by the order and steps of the interface and JS widgets rather than by anything explicit in code. The unhappy feedback loop continues as you get a system which can only be tested through the GUI, and it's no longer clear what parts of the app are deliberate rules versus incidental limitations.
- hodgesrm 9y ago
  On the flip side UIs are a very effective way to demonstrate ideas to users, so long as you keep them lightweight. If you want quick feedback on requirements build a UI.
- EnderMB 9y ago
  You've essentially described my interaction with dozens of agencies, where all projects are initially design-led and passed to the developers. It's funny how everything a (good) developer builds will match a written requirement, but often a design won't accurately match a set of functional requirements, and typically the non-functional requirements are nowhere to be found because, you know, we're agile and we don't have time to write pages of non-functional requirements to accurately scope our work...
RobertRoberts 9y ago
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... (https://cdn-images-1.medium.com/max/1600/1*tcNs35GceDxSGxAaFh-lSA.jpeg https://cdn-images-1.medium.com/max/1600/1*tcNs35GceDxSGxAaF...) 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?) 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.)
- TeMPOraL 9y ago
  Yeah; I'd say a comic strip like this seems useful to argue against the bottom workflow - it advocates spending time delivering 5 separate products instead of 1... But I suppose that's being pedantic :).
  - RobertRoberts 9y ago
    Maybe his analogies are off, and his communication is poor. Because I agree with the idea of starting small and getting going live sooner vs later. The biggest reason for this is my clients almost universally change their mind multiple times as development goes. So instead of 100 requirements to go live, I ask them to pick the 10 most important. We go live in 2 months instead of 6, and then by month 3, 30-40 of the original requirements are dismissed as unimportant, and 10 new ones are discovered. Real world use is an incredible tool to help determine real needs of the customer vs imagined needs generated from a committee.
  - kthejoker2 9y ago
    If the objective is to increase your speed, and I can deliver the 5 products in roughly the same amount of time as the 1, and each delivered product increases your speed, what's the problem, exactly?
    - TeMPOraL 9y ago
      > and I can deliver the 5 products in roughly the same amount of time as the 1 While this may work for software, sometimes, it definitely doesn't for vehicles.
OtterCoder 9y ago
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.
rawland 9y ago
Pardon me, if I'm wrong, but doesn't the article argue against its initial argument ("Code less, think more")? 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!". 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. 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.
Clubber 9y ago
>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. 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.
- nulagrithom 9y ago
  You stopped at the first sentence? Sheesh... You missed all the context. I read the link and it does indeed explain how his project failed because he wasn't continuously integrating his code in to the main branch. It's not just about CI, but actually _continuously_ integrating code.
  - Clubber 9y ago
    Then it should be, "Our project failed because we hired developers who didn't know how to use source control in a team environment, we never noticed, and we never established processes or expectations." CI is more than just source control, it's ticketing and associating tickets with branches, and automated deployment, automated unit testing, yadda yadda.
    - nulagrithom 9y ago
      https://en.wikipedia.org/wiki/Continuous_integration https://en.wikipedia.org/wiki/Continuous_integration
      - Clubber 9y ago
        You should read it. Of the 10 best practices in that article, three deal with committing. 4.1 Maintain a code repository 4.4 Everyone commits to the baseline every day 4.5 Every commit (to baseline) should be built It also includes the things I mentioned and a few others. 4.2 Automate the build 4.3 Make the build self-testing 4.6 Keep the build fast 4.7 Test in a clone of the production environment 4.8 Make it easy to get the latest deliverables 4.9 Everyone can see the results of the latest build 4.10 Automate deployment What was your point of linking that article? Are you agreeing that their problem was with source control and not that they didn't implement CI? Source control predates CI by quite a while.
zwieback 9y ago
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. 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.
ken 9y ago
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. 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. I think the organic path makes sense when each step on it is a simpler profitable company, not just a simpler product.
- barrkel 9y ago
  And with software - where you don't want to break what isn't broken - the car you build out of a skateboard frequently has weird shortcomings due to its origins.

115 points by treyhuffine 9y ago

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 » 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. I have a name for project like that, the name of a client I had from back in the days when I was younger. 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)

mrarjen 9y ago
This sounds like a real case of the client knows everything better, and only hired you so they could let you know they are better at your job. If only we could get those years of wasted development back.
treyhuffine 9y ago
That scene is too familiar. Trying to get a client to understand incremental delivery is probably more difficult than enforcing the practice on a team.
Terr_ 9y ago
I've observed something a little bit like this on some long-running internal business tools, where the "GUI-first development" approach also causes problems. Your data model ends up resembling the entry-forms and wizard-steps proposed by managers, rather than capturing the underlying ideas of the bounded-context. Since having it look right is so important, you also get a lot of business logic which lives closer to the GUI than it should. This makes it difficult to automate things because certain rules are soft-enforced by the order and steps of the interface and JS widgets rather than by anything explicit in code. The unhappy feedback loop continues as you get a system which can only be tested through the GUI, and it's no longer clear what parts of the app are deliberate rules versus incidental limitations.
hodgesrm 9y ago
On the flip side UIs are a very effective way to demonstrate ideas to users, so long as you keep them lightweight. If you want quick feedback on requirements build a UI.
EnderMB 9y ago
You've essentially described my interaction with dozens of agencies, where all projects are initially design-led and passed to the developers. It's funny how everything a (good) developer builds will match a written requirement, but often a design won't accurately match a set of functional requirements, and typically the non-functional requirements are nowhere to be found because, you know, we're agile and we don't have time to write pages of non-functional requirements to accurately scope our work...

RobertRoberts 9y ago

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... (https://cdn-images-1.medium.com/max/1600/1*tcNs35GceDxSGxAaFh-lSA.jpeg https://cdn-images-1.medium.com/max/1600/1*tcNs35GceDxSGxAaF...) 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?) 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.)

TeMPOraL 9y ago
Yeah; I'd say a comic strip like this seems useful to argue against the bottom workflow - it advocates spending time delivering 5 separate products instead of 1... But I suppose that's being pedantic :).
- RobertRoberts 9y ago
  Maybe his analogies are off, and his communication is poor. Because I agree with the idea of starting small and getting going live sooner vs later. The biggest reason for this is my clients almost universally change their mind multiple times as development goes. So instead of 100 requirements to go live, I ask them to pick the 10 most important. We go live in 2 months instead of 6, and then by month 3, 30-40 of the original requirements are dismissed as unimportant, and 10 new ones are discovered. Real world use is an incredible tool to help determine real needs of the customer vs imagined needs generated from a committee.
- kthejoker2 9y ago
  If the objective is to increase your speed, and I can deliver the 5 products in roughly the same amount of time as the 1, and each delivered product increases your speed, what's the problem, exactly?
  - TeMPOraL 9y ago
    > and I can deliver the 5 products in roughly the same amount of time as the 1 While this may work for software, sometimes, it definitely doesn't for vehicles.

OtterCoder 9y ago

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.

rawland 9y ago

Pardon me, if I'm wrong, but doesn't the article argue against its initial argument ("Code less, think more")? 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!". 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. 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.

Clubber 9y ago

>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. 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.

nulagrithom 9y ago
You stopped at the first sentence? Sheesh... You missed all the context. I read the link and it does indeed explain how his project failed because he wasn't continuously integrating his code in to the main branch. It's not just about CI, but actually _continuously_ integrating code.
- Clubber 9y ago
  Then it should be, "Our project failed because we hired developers who didn't know how to use source control in a team environment, we never noticed, and we never established processes or expectations." CI is more than just source control, it's ticketing and associating tickets with branches, and automated deployment, automated unit testing, yadda yadda.
  - nulagrithom 9y ago
    https://en.wikipedia.org/wiki/Continuous_integration https://en.wikipedia.org/wiki/Continuous_integration
    - Clubber 9y ago
      You should read it. Of the 10 best practices in that article, three deal with committing. 4.1 Maintain a code repository 4.4 Everyone commits to the baseline every day 4.5 Every commit (to baseline) should be built It also includes the things I mentioned and a few others. 4.2 Automate the build 4.3 Make the build self-testing 4.6 Keep the build fast 4.7 Test in a clone of the production environment 4.8 Make it easy to get the latest deliverables 4.9 Everyone can see the results of the latest build 4.10 Automate deployment What was your point of linking that article? Are you agreeing that their problem was with source control and not that they didn't implement CI? Source control predates CI by quite a while.

zwieback 9y ago

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. 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.

ken 9y ago

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. 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. I think the organic path makes sense when each step on it is a simpler profitable company, not just a simpler product.

barrkel 9y ago
And with software - where you don't want to break what isn't broken - the car you build out of a skateboard frequently has weird shortcomings due to its origins.