
How to Slow Down to Go Faster Than Ever in Software Development - myinnerbanjo
https://www.infoq.com/articles/slow-down-go-faster
======
taylodl
Paul Masson vineyards had a famous ad campaign with the tagline "we will sell
no wine before its time." So it is with software. We now understand computer
programming to be a craft in the order of coopering, blacksmithing or
whitesmithing in times of yore. As such, we've learned how to master that
craft.

First and foremost in the craft is continual iterative development and
deployment. When features are complete they're deployed. Non-technical
stakeholders determine the priorities of the features. Feature tests are
written by the stakeholders prior to the development of the feature (BDD).

Developers then implement the feature. They create the actual programming
artifacts (interfaces, modules, objects, functions, etc.) Tests are created
for these artifacts prior to their creation (TDD). Now I know my artifacts are
good and I know my features work properly - at least to the best of our
understanding today. If that understanding changes over time then the feature
tests change and the cycle repeats except now this time we have pre-existing
artifacts we can use to more rapidly implement the changes.

It's that simple. This is the craft of software development today. The
question I hear all the time from developers is _" But isn't this painfully
slow? You're spending all this time writing tests instead of actual code!_"
The answer to this question is NO, it's actually incredibly FAST!

Why?

Because you're gaining greater confidence in your programming artifacts as
time goes on. You _know_ they work. If you need to refactor something you
_know_ you can do it. This keeps your code flexible and pliable, ready to take
on new changes. So what's changing? Your requirements! Your requirements
aren't fixed up-front - they change as the business changes and as everyone's
understanding of the problem space changes. If your code isn't flexible and
pliable to handle that change then guess what? You're going to be spending A
LOT of time reworking the code. And it won't be any more flexible and pliable
than when you started. You'll have spent more time and money by the time you
get to the completion of the project AND your code is still brittle.

That's been my experience anyway - and I've been at this since 1985.

