personal development, Refactoring

Getting rid of technical debt

This post was inspired by excellent article by Bastian Buch, Effective Steps to reduce technical debt: An agile approach.

What is technical debt?

Technical debt may be considered as work that needs to be done to complete the project, but not done before delivering the product. I personally like to say that it’s all the undone work that makes developers proud or at least satisfied about the system they develop. It’s all about the issues that we promise to do in our less busy sprints, TODOs in code, sticky notes etc. It’s present in almost every project, but the only thing many of us do with it is complaining. Here is a list of ideas helpful to get rid of this debt using agile approach. It’s really hard because reducing technical debt is out of normal flow that is “implementing features”. That’s why you need a good plan to get rid of it.

1. Control technical debt

It’s not that technical debt comes from nowhere nor it’s that bad developers come to the team, make a mess and disappear. Technical debt starts with the lack of time. Initially it’s right – business value is more important than developers’ satisfaction. But then comes the deadline, another sprint in a rush and the team forgot to implement these unit tests, refactor this copy-pasted module or fix the hack in domain logic. Instead of trying to not create more technical debt, let’s try to control it in a proper way. One way is to have an inventory with items having a brief description. Then such a knowledge persists even if the only developer knowing the details has left the company.

2. Estimate & prioritize

After you gathered all the items in one place it’s time to put them in some order so that it’s easy to get something and just do it without analysis of the whole backlog. It’s good practice to order items in two dimensions: by their cost and returned value. The most important thing is to come to conclusion that cheapest but most valuable issues should be done first, and the most expensive with lowest value will probably never be done.

3. Visualize

The third, but the most important point is to visualize this inventory. This was a revolution that hit me while reading the article of Bastian. Before we had “TODO” items in code, but who knows how many. We had Onenote page (our wishlist) gathering all the things that we want to do for our project when we have time, but we just push items onto the list, never pull from it. We had “As a Developer I would like …” tasks in JIRA, but they were lost among hundreds of issues originating from “real” users. In all cases the inventory is hidden and the team pretends that there is no debt. But imagine that the inventory is visible next to the scrum board. Then it’s impossible to ignore the debt. You have an instant access to the inventory, both read and write. It’s clear when there are too many items. We go through this when we have a minute or two.

image

4. Put on a strategy

When everything is ready it’s time for the strategy: do the cheapest stuff in your innovation/research/study time (it should be around 20% of your capacity) – all in all such technical tasks is a great opportunity to sharpen your skills. More expensive tasks must wait for approval of Product Owner and come into a sprint with other issues. All in all you can always split them into smaller ones if you think that in that shape you can still benefit from them.

5. Involve Product Owner

Your product owner should know that you have debt. It’s the problem of the whole team. Tell him the cost of the debt (sometimes you need to realize it even for yourself). Sometimes it’s easy because implementing new features must be preceded by getting rid of the debt for some technical reason. Sometimes it’s harder, because of long term consequences of poor code coverage or just a mess in solution structure. All in all PO must be aware of it because they give the green light to do bigger issues as parts of the sprint.

Other ideas

Beside technical debt we also put on the same board optional technical tasks. Actually it fits the definition of “things to do to be proud of the system”.

We always wanted to try implementing gamification in our team and I think it’s a nice opportunity for us. By solving technical issues we get “virtual money” and we could praise ourselves for doing it. We can also track the average earning for each month. It’s always good to measure because such numbers motivate.

I really recommend to try it yourself

Advertisements
personal development, tools

Dev-team Awesomeness Quiz. List of development practices.

Hero-Envy-SupermanThis quiz is to let you evaluate your team/project in terms of good practices. Below you will find a list of different development practices/techniques. Mark the practices you use in your project and sum the points assigned to each technique. Then you can place yourself on the right place on the awesomeness scale. Be frank with yourself – don’t mark “UI testing” if you have one UI test that produces unknown result or “Friday (20% of time)” if you once stayed longer at work to do some refactoring.

Questions


Name
Description Points
Source Code Versioning Using SVN, Git, etc. (instead of shared disk space) 2
Using build server Separated machine compiling the solution, running tests and publishing the results 2
Automatic versioning Assigning application version by buildserver 1
Clean build No warnings while building the solution 1
Code quality rules Having and following a list of code quality rules checked by buildserver. Build fails if not passed 1
Code quality metrics Measuring “code coverage”, number of lines of code, number of unit tests, cyclomatic complexity 1
Separated tester role Having a tester whose only responsibility is testing the quality, doing regression tests etc 1
“One click” deployment Using WebDeploy or any other script that lets to deploy the software in less than few clicks 1
Continuous delivery Continuous integration + automated testing + continuous deployment 2
Database upgrade script Database migration is done automatically as part of deployment 1
Database refactoring Database is refactored, there is no left stored procedure/table, no “obsolete” fields 1
Pair programming Two developers + one computer 1
Code review Each commit/functionality is reviewed by another developer 2
External code audits Code review done by developers from the outside of the team 1
Friday (20% of time) Every month/week/”on Friday” stop doing productive staff and hold on to refactor something 1
Maintain central documentation, wiki Describe important information/workflows in one place and keep updating 1
Work agile Contact with client, work in iterations (not only Scrum) 1
Unit testing Non-production code testing small parts of production code 2
TDD Test-driven development: write test, write code, refactor 1
ATDD Specify requirements as automated tests 1
BDD Test whole behaviour not just parts of code 1
Discuss BDD scenarios with customer Customer utilise BDD scenarios, they can be written with specific language (i.e. Gherkin) 1
Non-back-end unit testing Unit testing of other parts of source code, for example JavaScript 1
Automated UI testing Automated tests of scenarios using user interface, using tools like Selenium, WatiN/WatiR 1
Performance testing Load tests, stress tests, analysing reports 1
Integration tests Automated testing of integration with other systems (i.e. exposed service endpoints) 1

Summary

1. [0 – 5 points] Ok, this is probably one-man academic project or a simple website. But at least you have found this list of ideas. Each month peek one and try to experiment. The benefits are invaluable! The great pleasure of seeing the build server full of green signs of passed tests… Can you imagine the feeling of safety when refactoring your code or UI? The instant feedback from users and the awesome feeling that you and your project are awesome and can be mentioned as an example to follow. This all is a bread and butter for mature teams.

2. [6 – 11 points] Is it that you are willing, but you don’t have time? No one does. Is your project too small? Notepad.exe has more that 200 UI tests. Think, that the next person that will take over your project in the next 6 months is a serial killer that knows your address.

3. [12 – 18 points] This is great that you came to this point. You passed the test. But be aware of the fact how many things you can improve. Remember that there are better projects, easier to maintain and refactor.

4. [19 – 25 points] Excellent work. This level is sometimes the maximum for some projects. Your team/project rules. People can actually mimic your way of working, I’m not telling that you must go now ask for a rise, but of course you can try :]

5. [25 – 31 points] You are simply awesome. You’ve reached the top. You are like Chuck Norris in development Texas and you turned “GodMode” in your project. Keep it up. PS: Do you still remember about earning money?

Final note

This was just my proposal of practices used by developers. It’d be fabulous if you add your ideas in the comment. I promise to add best ideas to the list!

You can also share your score if you want.

certificates, personal development

My desired certification path (as ASP.NET Developer)

It’s good to have a plan. If you have got a plan, the only thing needed is to follow the steps. Professional certification is one of many ways a counscious developer should follow. Later I’ll try to answer whether it is worth the effort or not, but first I’m attaching my personal diagram. It’s simplified version of the new certification path proposed by Microsoft altered with other interesting certificates. The one below is focused on Web Development mixed with Windows Store Apps but close to Web technologies (I think it’s good to be up-to-date with all the applications of HTML5 and JavaScript – that’s the demand of the market). certyficates

You can find here only the new path. Microsoft suggest to upgrade your skills from “MCPD 4” to the new MCSD/MCSM. Does it mean that former titles are deprecated? I think not. Companies will still develop bigger systems in not-so-old MVC 3.0 or WPF, but the trend is to go HTML5, no matter Web or Desktop. All in all, I still personally consider passing “Windows Applications Development with Microsoft .NET Framework 4” (just because I’ve been preparing myself for it for some time), but to strenghten your personal brand in marketplace it’s good not to stop.

Are certificates worthy?

I want this post to be short (there is a plenty of blog posts covering the topic), so that I’ll list pros and cons without further comments.
Advantages:

  • Your employer get additional point as Microsoft Partner – that’s why your boss wants to fund your exam. And it’s great deal for him because as a partner he has considerable discount for Microsoft tools and services.
  • Sales department can prepare better offer for customer – the offer is built upon company’s portfolio and competences of employees. Well-known certification is perfect way of proving them. But you have it in mind – you should not pass the full list of your certification center – choose only the known brands.
  • For freelancers – it’s very similar to the point above. Certification is the simplest way of convincing non-technical person (a.k.a. “customer”) to your competencies (blog posts, friends recommendations and stackoverflow rating may not be enough).
  • Certification lets you get in the door for an interview – people claim that they got hired because of certification. Of course job interview verifies the skills possessed not just papers, but it’s much more likely that headhunter invites certified specialist.
  • Preparing to exam – best if in group, creates an opportunity to share knowledge with others (not always connected with the subject of certificate – I remember great talk about R# shortcuts while preparing to EPiServer Exam), put pressure on exploring unknown areas of some technologies (like i.e. Accessibility in ASP.NET).

Disadvantages:

  • Practically no one requires them – myth, they not ask you about it in job offers or interview, but if there are two guys, for sure recruitment department would ask for the certified one.
  • Does not go in pair with skills, everyone can pass the exam – yes, that’s true. Everyone can go through braindump and pass.  That decreases the value of certificase. It’s even a two-edged sword – recruiter may want to prove that you do not possess certified skills. That’s why certification is not where you can just stop. But it’s like with University – everyone can finish, but if you do not have a title – you are eliminated without knowing.
  • The same time I can do something better – of course you can, but will you? That was my mindset, but then it’s hard to control yourself. In opposite, if the date of the exam is scheduled or you participate a study group, it puts pressure on following the path of your career.
  • Does not quarantee any financial bonus for you – can be true, but it’s not only about money (see “advantages” :] ).

Is certification enough?

The answer is obvious – not. Beside certification there are several, even more interesting activities and honors:

  • external courses and groups
  • posting board and social activity – like becoming MVP
  • blogging
  • beeing a speaker on public events
  • own portfolio, realizing open-source projects
  • In my opinion you have to go towards many paths in parallel. One day you prepare yourself to the exam and another you take care of your pet project. I think it’s about your self-discipline and that’s the reason why I want to continue with my path – I have just passed EPiServer CMS 6 exam and, while still motivated, I will try to organize with some group and pass the others from the diagram above. I encourage everyone to use or modify it (give me a sign in comment), maybe we can create something perfect together.