5 ms·

How to Slow Down to Go Faster Than Ever in Software Development

3 points by myinnerbanjo 8y ago

taylodl 8y ago
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.

3 points by myinnerbanjo 8y ago

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.