Code Less, Think More… Incrementally | Hacker News Reader

Code Less, Think More… Incrementally

levelup.gitconnected.com

115 pointstreyhuffine32 comments

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)

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.

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.

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.

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.

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

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

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

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.

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?

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

What I think he is trying to say with the cartoon is that you should start with a "walking skeleton". Do up just enough UI, middle layer and back end to get the data going back and forth. Then start adding features, refactoring and re-architecting from there.

No I get the point, but try and build a walking skeleton (ie, skateboard without first starting with the wheels/feet.

If you are critical for a moment, you can see these two concepts are not dissimilar. No matter what, you always have to make the smallest part first and add onto it.

Seriously, steps 1-4 building the large car are the exact same steps needed to build the small skateboard.

I think he's really trying to say "lower your requirements to go live", and then from their do incremental improvements. Does that seem like a fair assessment?

> Seriously, steps 1-4 building the large car are the exact same steps needed to build the small skateboard.

They are, but the scale is vastly different.

> I think he's really trying to say "lower your requirements to go live", and then from their do incremental improvements. Does that seem like a fair assessment?

Sure.

> I think he's really trying to say "lower your requirements to go live", and then from their do incremental improvements.

No, what he is saying is get your product working as soon a possible, then incrementally improve the components until you have the functionality to go live. That "go live" point (based on the smiley faces) is either the scooter (no longer unhappy) or the motorcycle (first happy face).

Of course you have to build things in steps. The idea is that you build something smaller/simpler first that delivers some value to the customer that requires way less steps than the complicated thing.

Building a car requires many thousands of steps/tasks, a skateboard requires much less. It's easier to estimate how long a skateboard will take to build, therefore making it more likely to be done in a reasonable time, giving you the ability to give your customer a better transportation option than walking. That then buys you time to work on the next more complicated option. And so on.

The other point that should be made about this process, is that it gives your customer a chance to realize they don't really need that complicated big thing. Maybe you build them the bike and they realize that's perfectly sufficient for their needs and then they just say the project is done. You'd never have that opportunity if in the same time it takes to build a bike, you're 25% done with an unusable car.

Most customers vastly overestimate the solution they need. Your goal as a product manager is to build incrementally and constantly challenge the problem definition.

>Most customers vastly overestimate the solution they need. Your goal as a product manager is to build incrementally and constantly challenge the problem definition.

I agree, hence the term "minimum viable product", I have found this term sums up the entire argument we are all having. And I think almost everyone here is saying the same thing with different phrasing.

We all know that if you want a vehicle to move you from point A to Point B, wheels are a good start, no matter the size of the vehicle or the speed required. Making the wheels bigger later to go faster just makes sense from a software perspective.

And after a month on a scooter, the client may realize they don't need anything more than a scooter, and may be grateful we didn't build them a car like they originally asked for.

> When I start at step 1 with the skate board, it looks like the first part of the cartoon...

They key part is that that skateboard has much simpler and easy to build wheels and chassis than a car. A car chassis with care wheels is harder to build that a skateboard, and unlike a skateboard, can't actually be used for anything. If we are talking real world costs, a fully functional car wheel costs more than a whole skateboard.

The point is: Don't to build individual systems one by one and wait to have a working product until every system has been fully completed. Instead, build barebones versions of the necessary systems so that you can get a working product ASAP, then improve the systems incrementally.

This goes beyond just building a MVP. Instead you just build a MWP which is a "minimum working product" and iterate on it until you have built something viable. The skateboard may not actually be a MVP, you may not reach MVP until you have a bicycle or a motorcycle.

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.

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.

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.

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.

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.

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.

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.

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.

https://en.wikipedia.org/wiki/Continuous_integration

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.

First sentence of the article: In software engineering, continuous integration (CI) is the practice of merging all developer working copies to a shared mainline several times a day.

Guy didn't do that. His project blew up. He failed the basic premise of CI, and his project blew up. I'm not sure how much more clear it can be: his project failed because he didn't do continuous integration. He _did_ use version, as did everyone else in the company. But he didn't do continuous integration. And his project blew up. Ergo, the statement that caused you to immediately stop reading: "The post describes how a 6 months project failed because it didn't implement the principles of Continuous Integration."

Yes, but CI is way more than just merging and source control, that's just the source control part. That part predates CI by 10 years. You can have source control and merging without CI. I'm reading from you that you are saying that if you merge branches you are implementing CI. There is a lot more to it. It's in the article you linked. He failed at source control (and really management processes) not because he didn't implement CI as claimed.

I don't know why I'm indulging your pedantry, and I think I'll stop after this, but what I'm reading from you is the following:

Because he only failed at continuously merging his code and writing tests, but didn't explicitly mention that there was no build server, then he didn't fail at continuous integration. He only failed at version control despite the fact that they were using CVS, were branching and merging appropriately, but were not doing so in the rapid fashion that became prevalent 10 years after version control. Additionally, because projects have managed to succeed without continuous integration at all, the rest of the original article that simply mentions his "questionable" CI failure is not even worth reading (but is certainly worth commenting on).

Disregarding how closed-minded it is to dismiss both articles based on that single sentence, by implementing proper CI he would've covered all these "version control" issues anyway. I think it's fair to call that a CI failure, as it does fall under the blanket of good CI practices.

Secondly, I think your bar for "success" is too low if you're willing to throw out "ticketing, automated deployment, and automated unit testing" but still call a project a success. I'd call that an inevitable clusterfuck regardless of how well it runs at the moment. Without these CI basics it's going to suck to maintain that system in just a few short years. I really, really hate dealing with systems that were built without these should-be-obvious basics.

>I don't know why I'm indulging your pedantry, and I think I'll stop after this, but what I'm reading from you is the following:

I don't know why you are either. Glad you stopped. I'm not really interested in your opinion on my opinion. I tried to explain my position on why I didn't like it, but you just wanted to argue uselessly and thankfully not endlessly. Bottom line: I didn't like the article's first paragraph. Deal with it.

Reply on news.ycombinator.com