... I'm breaking down the technical debt concept for product stakeholders.
Big decisions are often fraught with risk. Sometimes though the only way to make the right decision though is to test the options first.
For the last few months I've been working on a CMS application for a client that has been steadily growing in size. We both agree that there will come a time where we will need to make some decisions about the design of the application so that it remains easy enough to maintain and develop but also scales up with the client's expected growth for the next few years.
It's something we've both been putting off for some time now, but with more projects and clients appearing in the client's pipeline, we've decided that now is the right time to start making these decisions.
The problem has always been though that if we make the wrong decision we end up too far down a path that we don't want to be. Backtracking might not be an option and working towards a different solution is something that we don't want to end up doing either.
The answer to this dilemma has been surprising simple. For each technical decision we have to make, we have a number of options that we can consider. Rather than analysing and committing to the most attractive option (in theory anyway), we have decided to take a day and implement that option in a single day to see where we get to. If by the end of the day, we're still happy that we've made the right decision, then we continue on with this option. If we're starting to have doubts, we abandon the option and try something else.
Software developers will recognise this concept as a spike. This is the idea that you carry out enough work to recognise the risks and knowledge that are associated with change in design or functionality. The spike gives the developer the chance to find out the risk and complexity involved in such a change. With the information, developers can provide better estimates for these changes or completely rule out a change.
The spike is a great way to ensure that you limit risk from a decision without committing to that decision. It will involve some time to determine if the option you are spiking is worth pursuing, there's no getting around it. However it is better to invest some time in pursuing the right decision rather than blindly committing to the wrong decision is it not?
I'm coming to the end of a project with a client. In the past I would have made sure the client was happy, closed the project off and collected the rest of my fee for the work. So would many freelancers. The work is done, you're done. Right? Maybe not.
Over the last few months a number of projects have been started and finished with the same client. This has led to a familiarity that is great for day to day communication, but as a working team we have become complacent in the work we are doing and there is clearly room for improvement in how we work together to finish each project.
In an agile team, frequent retrospectives are used to find out what's working for the team, what isn't and areas where the team can improve. It's a time of reflection. As part of a my pledge to deliver a professional service, I'm am now going to give a retrospective for each project that I finish with a client.
Essentially it's a report of three areas. Developers will recognize the questions as they are the same questions asked when an agile team gets together for their own retrospective. So why not apply the same idea to client work as well?
1. Where did we go wrong?
Admitting where a project went wrong can be difficult for all concerned. It's not a finger-pointing exercise though. If you think I'm picking at your faults, then you're probably not the type of client I want to work with. We're simply trying to isolate the problems areas so that we can change them for the better.
2. Where did we do well?
Highlighting where a project went well is important for any future work I do with a client. This is often over looked and we should never just think the work that is done on time and within budget is okay. If work is carried out within these constraints, then recognising that success is a great area to start for future projects. I want to build on a set of good practices that we both recognise so that future projects become easier to do.
3. Where could we improve?
We found out where we went wrong from the first question, but is there something we can do to fix this for future projects? If we are to continue working together, then it would benefit everyone if we could gradually improve on projects in the past. Less bumps on the road means projects can be finished to a higher quality, on schedule and with-in our agreed budget. Who doesn't want to work like that?
I have a first retrospective coming up in the next couple of weeks, and I've already collected a number of different observations from the project where both myself and the client could improve. Not all clients will be happy to read the retrospective or even take any advice from it. That's okay, it's their choice. For those clients that want to improve on future projects when working with me, I'll be more than happy to help them resolve problems from the retrospective and suggest recommendations for future projects with them.
The project doesn't end with the last commit or deploy, it ends when I've exceeded the expectations of the client and helped them get the most from our time together working on a project.
Alan Francis wrote a really great article at the start of December about how he wanted to get back to his Extreme Programming roots and start programming deliberately. If it's too much for some of you then here's a non-programmer translation.
Programming by coincidence is where programmers make assumptions on the code that they are writing. These assumptions lead to code that isn't completely tested and could lead to problems in the application the code was written for. It's like acting on automatic pilot.
I looked back at the last year of programming I did. I opened the project I had been working on for the most of last year and did a code review on it. In general the code was okay, there were tests to cover the core requirements, and I had refactored when I could, gradually trying to improve the code with each iteration. However there was still gaping holes in the code that I should have investigated further. These parts of the code are tested but they are not tested extensively for edge cases, and that's where the bugs can happen.
When I was first introduced to agile methodologies in software development, I read the Extreme Programming website and another book, The Pragmatic Programmer. Both were excellent sources of information and let me taking my first steps in the agile world. Since then I've tried to improve my agile skills with every project I do.
After reviewing the code of the project in question, I couldn't see evidence of an improvement from my time working on the codebase. I seen lots of features that I implemented, but not much else in terms of improvements in the making the code better. When I thought back, I was aware of the features I was implementing but I didn't take the time to really think through the features and their impact on the code. It hasn't cost me any late nights in terms of application crashes, but it's not a road I want to go down.
So this year I'm focusing on a little bit of a reboot for my software development skills. Out goes the new programming languages, the new project ideas and the rest of the programming books I promised myself to read. Back in comes a collection of programming books that I haven't read in over 10 years, but books that I know will get me back on the right path again.
The good habits and practices of great programmers haven't changed much over the years and they probably won't for the next few years. Programming languages and frameworks will come and go, but the ideals and skills that many programmers pursue are still the same as they were 10 years ago. Sometimes it just needs a little time to remember them and go over them again.
Estimating. It's a word that can strike fear into people who are new to the realms of programming, project management, freelancing and other careers. The daunting prospect of estimating the length of time at which you will be able to complete a set piece of work.
I have over ten years experience in the realm of software development and sometimes I still get it wrong. I've seen developers get their estimates wrong by a couple of weeks and project managers miss their target deadline by months. So why are estimates so hard then?
The first reason is that the estimate is based on a bigger block of work, rather than multiple smaller ones. Estimating a project from just an outline of the project is a rookie mistake. When you estimate on a large single block of work, you are basically playing a guessing game. In fact your estimate is always going to be wrong when you do this.
Instead, break your big block of work down into smaller blocks of work. The more granular you get, the easier the estimate is going to be. It won't always be correct, but your estimate will be more accurate.The second reason is information. We are limited by our little brains in how much information we can retain when estimating on a project.
When it came to estimating on projects for ERP software customers, I had to remember that different customers had different workflows in their systems. No two systems were the same. I had to factor in that a customer will have specific workflows in their system that I need to either work around or work with. This job was made a lot easier by the fact that I used notes that I kept on each customer's system so that I was ready to make better estimates in the future.
Now I know this might not be easy to do for a new project where you have little information, but carrying any information that is relevant from one project to the next is going to make estimating on blocks of work a lot easier.
Estimating isn't a black art, it's simply something that requires you take the time to break blocks of work down into smaller chunks and if you can, have the right information at hand to make better estimates on those blocks of work.