why bother about code quality from scratch
TRANSCRIPT
Why bother about software quality from scratch?
Servan Huegen Co-founder, Operations, Agile Coach @ Node1
1
Software development
And there we go. We’re ready to start our new software development project. The creation of a new app, website or
back office system. In a corporate or a small start-up. No matter how big the project, you’ll always have some roles involved, like the budget holder, the business owner of the
product, some geeks in a development team and a guy or a girl who does some coordination; the Scrum Master.
What can happen if there is to less focus on code quality from the start? Read on! Or jump to slide 12 if you’re not interested
in an animated story based on my own experience.
Customers love new stuff, a lot of itWe’re all customers in some kind of way, so with a bit of empathy we’ll all understand the customers’ need of new
stuff. Meet the Product Owner. The guy or girl who is mandated by the budget holder and other (business)
stakeholders to make decisions about the software product.
Green field software development is great!Software developers really love green field development. Deliver new stuff, a lot of it. No legacy. No workarounds. Choose the latest tooling, libraries and development language. Create stuff from scratch. And last but not least.. no bugs. NONE! ...well, at least for a while.
Lets deliver new stuff…
And we’re off. Software development environment in place. Installed the latest real handy chat tool. Trail versions of the latest sexy services installed. And yes, start with a crispy new backlog. A backlog without those distracting bugs. No bugs on the backlog! Lets start to make the Product Owner happy. Very happy. Deliver new stuff, a lot of it. “Can’t you add this, please add that”. Yes sire! “I like new stuff”. We like new stuff you mighty owner, so your wish is our command. Deliver this, deliver that. Happy
…a lot of new stuff
“Can't you deliver more during one sprint? Faster? More? More!!” Yes we can dear Product Owner! Bring in more developers and we can deliver more and make you more happy. “Mmmm, not enough budget for more developers.. But wait. This test dude or how you call it, the QA guy or whatever. Lets replace this guy with a new developer. Problem solved!” … And look at all those new features, they where not on the backlog, but so easy to implement and fun to use! Never seen a happier Product Owner and development team together. BFF!
Go live is heaven
Ladies and Gentleman… We. Are. Live! 🎉👻💃🍾
Well, not really live, some kind of semi-live. We know the
theory of the Minimum Viable Product aka MVP, so we share our first product to a closed user group of course. We don’t
want to fail for the big audience via the App and Play Stores,
because you’ll never get a second change for a first impression.
The first users take their job seriously. Family and friends, thus critical. That’s what we like!
Hello buggies
Besides the good feedback the closed user group gives, they find some bugs, just some small ones. … Lets kill them all. Yeah!!
Bugger off!
Developers like to develop new stuff, they love it. Product Owners like new stuff, a lot of it. So a match made in heaven,
isn’t it? Now we’re really live and more and more users likes to use
our app. Those Facebook and Google campaigns really work! More users comes in hand with more bugs. More bugs, even more bugs.
The top of the backlog is filled up with it. We have enough bugs for at least five weeks of bug fixing. And again more
and more bugs are found. Where do they come from?!?
From heaven to hell
The team need to focus on bug fixing and can’t deliver new
stuff. For the Product Owner it’s pretty hard to accept this. She loves new stuff, a lot of it!
But ok, the first and second week she accepts the situation. “Lets kill the bugs. …and please two new features? Please?” At the start of the third sprint the Product Owner goes
bananas. Still an enormous list of bugs and no room for new stuff..
“I HATE BUGS, I LIKE NEW STUFF!”, she cries out loud. … After a short meeting between the budget holder and the
Product Owner they decide to replace the team. “What a bunch of development cowboys, we need a new team. A
team with real pros!”
Green field development is great
The new team is in place. This bunch of geeks are real pros! They took a quick look at the smelly bunch of old legacy code and came to the joint conclusion to start from scratch. No more bugs. Lets focus on new stuff. They are pros and pros want to create stuff, they love it. The Product Owner accepts the delay, because she likes new stuff, a lot of it.
And there we go again…
What went wrong?
A couple of things can go wrong during a software development project. Let’s focus on the the most important once to improve:
1. No focus on code quality from the start
2. Unexperienced and/or incompetent individuals
3. The team is imperfect
4. Incorrect understanding of a MVP
5. Avoid developers paradise
Let’s explain them in more detail:
1. No focus on code quality from the start
Product Owner got an huge need of new stuff. Software developers got an huge need of new stuff. One and one makes two. If they only focus on delivering new stuff and no focus on testing
and bug fixing from the start, they will pay the price when product goed live. The users will find
bugs and probably a lot of them. You can’t ignore the bugs, because you can’t ignore your
valuable users. Fixing those bugs will cost a lot of time and during that time you can’t deliver new
stuff, well at least not a lot. And by introducing new stuff, you’ll introduce new bugs…
Solution?
Always focus on good code quality even if this holds back the velocity to deliver new stuff.
Otherwise you’ll have to pay the price when you go live. Always execute unit tests[1], regression
tests[2], cross browser tests[3], peer reviews[4], what ever it take to build and implement solid
software. Add this to your Definition of Done[5] (DoD) and stick to it. Everything which not
passed the DoD, can’t go to production!
2. Unexperienced and / or incompetent individuals
The Product Owner and the development team had to much focus on delivering new features and to less focus on good code quality. How could this happen? Easy; put an unexperienced Product Owner in one room with a bunch of well-meaning geeks without an experienced Scrum Master. How to solve this? Dear Scrum Master, first of all visit a good Scrum course. Then, coach the product owner, budget holders, stakeholders and development team. Indoctrinate, brainwash, explain till they drop. No matter
which method you choose, as long as they start to understand -as soon as possible- the impact of choosing new functionality from the start above good code quality. If they ignore quality from the start they’ll get a pretty bad trip after going live in the real world, with real users.
Secondly, from the start, make a reservation for quality assurance and refactoring[6].
Last, understand that Product Owners, developers, budget holders wants to have new stuff, a lot of it!
3. The imperfect team
A hustler, a hipster and one or more hackers in one room doesn’t make a perfect (start-
up) team automatically. As Bruce Tuckman already explain in the mid 60’s, it’s about
forming, storming, norming, and performing[7].
The team reaches the performing stage, when hard work leads, without friction, to the
achievement of the team's goal. The team is aligned and autonome.
Popcorn time! Sit back and relax, see two entertaining video’s about Spotify’s
engineering culture[8].
4. Incorrect understanding of a Minimum Viable Product
Nope, a MVP is not the 1.0 version which you share with the world via the App and Play stores.
“Obvious!” you think of course. Not so obvious as you think. A lot of product owners, budget
holders, newbies and AINO[9]-lovers are convinced about this.
Please read and understand the Wiki page about the Minimum Viable Product[10]. Then, take a
good look at the Lean Startup[11] principles.
A MVP isn’t a 1.0 version you’ve developed safely in your nice isolated crispy fresh quasi-industrial
hipster joint, thinking you’ll exactly know what your users wants. First of all, who are your first
users? Secondly, gather what they really like, ask them in real live, get out of your building[12]!
Take a break, get your favo half-frozen-triple-soja-decaf-frappuccino and read this great blog
called “Your Startup's First Thousand Decisions Don't Matter (But These Two Do)[13]”. Followed by
another blogpost called “Minimum Viable Product #MVP isn’t quite what it claims to be[14]”.
Happy reading!
5. Last but not least: avoid developers paradise
First of all, an optimal performing software development team is in charge of HOW stuff will be created. The Product Owner, on the other hand, is responsible for WHAT need to be created and in which sequence.
Software developers love to develop software. They get a real kick when they can create this microseconds-responding microservice-based architecture, scaleable for at least 900 million monthly active users -just like Facebook- system. From scratch. Huh? I thought we’re creating a MVP? Yes, but you’ll never know, you know. We’re creating the new Facebook, right? And by the way, we’ve implemented this crispy new service in just two days and I’ve added some stuff which looks really nice, but we have really no idea if the users will love it. And we’ve created even more nice stuff which was not on the backlog. Software developers really love to develop stuff, a lot of it, even when you can buy a service with the same functionality and more for a small bargain. Do check on a frequent bases the availability and matureness of the services you’ll need. Solution? Dear Product Owner; keep focused on the stuff the development team delivers. If they do more than asked, explain that in the same time some of your items on top of the backlog could have been burned! Dear Scrum Master; coach the Product Owner and the team. Let them focus on the top of the backlog.
Read more about SaaS Integration: Build, Buy, or Subscribe[15].
References1. Unit testing https://en.wikipedia.org/wiki/Unit_testing
2. Regression testing https://en.wikipedia.org/wiki/Regression_testing
3. Cross browser testing http://mashable.com/2014/02/26/browser-testing-tools/#qD8Op__6gkq5
4. Peer reviews https://en.wikipedia.org/wiki/Software_peer_review
5. Definition of Done https://www.agilealliance.org/glossary/definition-of-done/
6. Software code refactoring https://en.wikipedia.org/wiki/Code_refactoring
7. Forming, storming, norming, and performing https://www.mindtools.com/pages/article/newLDR_86.htm
8. Spotify’s engineering culture https://labs.spotify.com/2014/03/27/spotify-engineering-culture-part-1/
9. Agile In Name Only (AINO) http://noop.nl/2008/02/aino-agile-in-n.html
10. Minimal Viable Product (MVP) https://en.wikipedia.org/wiki/Minimum_viable_product
11. Lean Startup http://2015.leanstartup.co/day-2-5-principles-of-lean-startup/
12. Get out of your building http://www.inc.com/steve-blank/key-to-success-getting-out-of-building.html
13. Your Startup's First Thousand Decisions Don't Matter (But These Two Do)
https://www.fastcompany.com/3061435/lessons-learned/guess-what-startup-founders-your-first-50-decisions-dont-matter-but-these-tw
14. Minimum Viable Product #MVP isn’t quite what it claims to be
http://manojranaweera.me/2014/09/15/minimum-viable-product-mvp-isnt-quite-what-it-claims-to-be
15. SaaS Integration: Build, Buy, or Subscribe https://www.mulesoft.com/resources/cloudhub/build-buy-saas-integration
Thank you!Don’t hesitate to contact me if you have any questions.
19
Servan Huegen Co-founder, Operations, Agile Coach @ Node1
+31 615 028 768
