Inside Sitecore we work with Scrum. This simply means that we have the business prioritize business cases and technical teams try to implement them as good as possible. Over the years we’ve learned a lot about application development and one of those things was that we’ve to prioritize technical tasks in a similar fashion as business cases. Obviously these don’t go always hand in hand. A simple update of the Sitecore platform(for example Update-1 to Update-3) isn’t an obvious task for the business. In this particular case, there were only two new features in the platform:
- New Channel Performance report inside the Insight Dashboards which shows which channels drive most value.
- The Content Editor allows you now to display [shared] and [unversioned] to end users, to simplify translation projects
When we did the upgrade, we saw a decrease of performance on our production environment. I’ve heard from many sides internally the unfunded conclusion that ‘6.6 Update-3’ is a bad and slow release. Interesting thought… But reality was different. Last Monday we released another version of the website, but with the same version: 6.6 Update-3. In the end of the story, if you give people new features, you can never roll back.
The cause seemed to be in the combination of some new relative slow features, infrastructural problems and deprioritized technical tasks. Let’s focus on the last ones. Let’s assume that the Technical Task was something along the lines ‘optimize the custom item manager’. As a business user it’s quite hard to judge whether this adds value. A developer never tells you that it’s causing a 25% decrease of your website.
So what can you do to solve this challenge? I guess we all do know that we can do performance testing. But that in itself doesn’t change the mind of the business owner, who wants to have a quick time-to-market. The solution for that is to agree on the experience. A simple way is to decide together with your business owner what is allowed. For example: every server page needs to be generated and transferred in less than 500ms. This allows a browser load of less than 3 seconds.
Out of the sudden, this small technical task makes sense for the business user, because a developer talks his language. It’s a no-brainer but it happens a lot. It’s not related to the project process you’re using. Scrum has a Definition of Done while using Prince II, you’ll talk about deliverables.
Still it doesn’t justify refactoring of your code. It’s obvious that a business owner doesn’t see the value in that. It can even slow you down a lot! There are easy ways to show technical debt like this in relation to team performance, but you need to have a lot of tooling before you can make this visible. Most of the time you don’t have those, so let’s make it more concrete.
Refactoring is all based on making the same thing do the same job, but in a more maintainable way. If you’re doing code and performance optimizations at the same time, you’ll end up in the situation where the system performs well, but you’ve broken all functionality. So split it. Refactoring shouldn’t optimize stuff, but is polishing for you and your team mates.
Still it doesn’t justify why you’re doing it. But it makes it easier to explain to your boss or business owner: I made it maintainable.
Interestingly enough, that’s enough explanation for your boss or business owner. As part of your work, you’ve introduced 3 things:
- Meeting the desired functionality (the feature works)
- Meeting the desired quality standards (it performs well, it looks good, it validates, etc)
- It’s ready to enhance further (because it’s maintainable)
So let’s assume they still don’t take it. Then make a list of the crappy stuff and explain in this list why you didn’t do it. Every time in the near future when you’ve to touch an area which is already build, show this list and show what you need to do to start working on it. In the end of the story it’s crappy code you’ve to work with.
Estimations will increase when you touch it again. The shock effect when you explain this is big. You can see it in the eyes of anyone who owns the budget where you are working with. You can go in the ‘told you so mode’. You’re allowed to do this once. Next time, propose to do it straight away, but as part as a simple flow when creating a new feature:
- First: Meet desired functionality
- Meet desired quality
- Meet desired code quality
- Do the check-in
Note: I make some shortcuts here. I do ignore all stuff like Test Driven Development, BDD, Pair Programming, etc. Why? Because they don’t add value to your business. Tests are cool for you. Because you like Green Checkboxes. The Business likes money. So what? Meet each other in the middle. Explain to them in a simplified way why you do stuff. Why Technical Debt matter. Why performance agreements matter. Make it visible. Fail on purpose. Learning is done by failing, not by showing I did according to the book. It’s sad but it’s damn true. But please, try to fail before you go to production …