It's a short book (about 200 pages), and I definitely recommend it to anyone who is in the development field. I didn't really come here to review the book but to put down some of my thoughts on the subject.
Development Teams as Suppliers
Over the last few months, I've been thinking more about the state of development and development teams in most companies. I've talked to colleagues who have had really bad experiences at their company and to colleagues who have had really good experiences. What distinguishes the two? And is there any way to influence the company you work at to move in a better direction?
Many times, the software development division is seen as completely separate from the rest of the company. The division is there to do the bidding of the business. What I would like to see is that the software division is seen just like any other department in the company. Here's an example of someone who was looking for this same thing:
At a previous company, I had an I.T. Vice President who had a goal: he wanted to be asked about the color of the carpet in the new building. This is just a trivial example of the type of question he wanted to be asked, but that's sort of the point. The company would come to him whenever they had issues that required a technical solution, but that was it. He noticed that in executive meetings where they would discuss the "color of the carpet", input would be requested from HR and Marketing and Finance even though the question didn't have anything to do with those specific divisions.
These other divisions were seen as a true part of the company while I.T. was seen as a supplier. His goal was to get I.T. into the same position as the other divisions of the company. Sadly, I don't believe that he ever achieved that goal, but I have a better understanding now of why he was pursuing it.
Moving from a Supplier to a Partner
So, the question is: how do development teams make the transition from supplier to partner? I wish I had a good answer to this. I've worked in several different environments. In some, the developers were truly partnered with the business. As an individual developer, I spent time with the users out in the business area. I would go and watch them work for a day to see what types of issues they had in their current environment. The goal was to understand the difference between what they think they need to make things more efficient and what they actually need to make things efficient.
Part of the reason this is necessary is that the business users generally do not have a good idea of what is possible. And even if they do have a good sense of what is possible, they may not be able to tell the difference between what is easy and what is hard. That's where we really need to step up and fill that role.
As an example: on a particular application, I was building a data verification screen. Because I had spent time with the users, I knew their workflow and how they kept track of their various activities. So, even though it was not requested, I suggested that a "print" button be added to a particular screen. This turned out to be a huge win from the user's point of view.
I was able to make this suggestion due to a few reasons: First, I knew what the users needed -- this was based on me watching and understanding their workflow. Next, I knew it was an "easy win". I had recently implemented a similar print functionality on another application, so this was literally 5 minutes worth of work.
These are the types of situations that I live for -- being able to go above and beyond the users expectation while still staying within project scope.
Project Scope and Estimation
Project scope is always a difficult subject to deal with. The business areas are generally making additional requests throughout the development process. This is how we ended up with Agile and other methodologies that are focused on constantly re-evaluating the scope and implementation periods for certain features. Delivering quickly and delivering often really sounds like a good idea, but the reality of most of the projects that I have worked on is that there was a certain "critical mass" that had to be reached before the software could be released. Once this "critical mass" is hit, then other features can be added. But often, the initial release takes a while to get out.
Estimation is a big topic in The Clean Coder (as it should be). That's because we, as developers, are historically unrealistic with our estimates. We generally fall into 2 groups: those who grossly underestimate, and those who grossly overestimate.
Under-estimation can be due to developers simply not thinking it through. Or because the developer doesn't really understand his skillset. Or because the developer likes to be seen as the "hero" -- someone who can turn around things inordinately quickly.
Over-estimation can be due to developers not having enough information. Or because the work does not excite the developer. Or because of ineffective time management.
Perfect estimation is a near impossibility in our industry. After all, what other business is asked to come up with concrete time frames for things that have never been done before? And this varies greatly depending on whether we are doing coarse-grained or fine-grained estimates. With coarse-grained estimates, we probably have not done enough analysis to really know how long things will take. With fine-grained estimates, we could end up with many small errors that get compounded when all of the estimates are added together.
I had one extremely good manager who understood her developers. She knew that when John gave her an estimate, she should multiply it by 2. When Janice gave an estimate, it was about 50% high. And when Kevin gave an estimate, she should divide it by 3. (Note: all names have been changed to protect the innocent.) Because of this, the manager made our team look good to the business. We hit our time frames pretty consistently (and much more consistently than other teams in the division).
Learning to Say No
One interesting topic in The Clean Coder involves learning to say no. By our nature, we want to make people happy. That's why we build software -- to meet someone else's needs in a way that we can take pride in.
Because of this, if we are asked if we can make something happen more quickly, we have a tendency to say yes. This may be because we are engrossed in a feature that we want to get completed (and so we are probably going to spend extra time anyway), or just because we want to be seen as a "team player".
Uncle Bob argues that if we are making good (realistic) estimates, then we can't complete the job any faster. If it is possible to get a job done in 4 days instead of 5, then we were off by 25% in our estimate. If we can only get the job done by working that 5th day after hours (an extra 2 hours a day for 4 days), then that means our estimate was correct; however, we really need to worry about the perception.
Working that extra 2 hours a day for 4 days is probably not going to cause any problems. But if we make this concession in one case, then we will be asked to do it again -- probably repeatedly. Because of this, we need to not simply say yes, but to make sure that the people we are promising understand the extra effort that will be required.
In the example above (4 days vs. 5 days), if the manager says that they really need something done on Thursday (due to a hard deadline somewhere), then you could say that you are willing to put in extra hours for 4 days in order to hit the date, but that you will not be coming in on that 5th day.
This may sound a little extreme, but I have had the experience of working way too many hours which had a detrimental effect on me. We were working on a quarterly release for a product. I had been tracking it for several months, and (from what I could tell) we were going to make our release date. When it came to "crunch time" there was still a lot of work to do, so I was working evenings and weekends to make sure that my part of the process was complete. Due to some things out of my control, the release date was moved another two weeks. And then another 4 weeks. And then another 2 weeks.
The upshot was that I ended up in "crunch time" for 4 months. This was a terrible situation to be in. Whenever I saw my work laptop, I was thinking about all of the things that I needed to do. I was working weekends to try to get things out on Monday morning. I dreaded getting up each morning because all I could think about was how much unfinished work I had. I let myself burn out.
Notice that I said that "I let myself". I was in full control of the situation. At any time, I could have taken a day off or not worked late into the evening. But I wasn't letting myself do that. I was too wrapped up in the work to have a good perspective.
Remember: it's just software. If you are late with your work, no one is going to die (with very rare exceptions). Part of being a "team player" is understanding that you cannot be an effective player if you are not at the top of your game. And it's impossible to be at the top of your game if you are constantly running non-stop. Take time to breathe. Take time to relax. Take time to refresh yourself.
And remember that it's okay to say no.
The Clean Coder contains many nuggets of wisdom. Unfortunately, when you read the book, you'll probably say, "Well, that's obvious." Most of the things are -- they cover how to be a responsible professional. But for some reason, this is missing in our industry (or at least perceived to be missing). By focusing on how we can better ourselves and behave as professionals, we can have an impact on our own company and spread this thinking further in the industry.