
Code Less, Think More… Incrementally - treyhuffine
https://levelup.gitconnected.com/code-less-think-more-incrementally-98adee22df9b?ref=HN
======
JeanMarcS
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)

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

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

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

~~~
kthejoker2
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
> _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.

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

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

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

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

------
Clubber
>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
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
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
[https://en.wikipedia.org/wiki/Continuous_integration](https://en.wikipedia.org/wiki/Continuous_integration)

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

~~~
nulagrithom
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."

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

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

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

