Velocity Inflation Triggers Productivity Recession 6
A team’s velocity is a measure of its productivity. A higher velocity means more work is being completed each iteration and a team that shows an increasing velocity from iteration to iteration is being more and more productive. This isn’t necessarily a good thing.
In Extreme Programming (XP), a team’s velocity is defined as the number of story points completed in an iteration. We can track the velocity for each iteration and calculate the average velocity over several iterations. If we know how many story points comprise an application, we can even project when an application can be released . Velocity is a very useful measure of a team’s capabilities. I have found it to be a much more reliable (make that infinitely more reliable) number to be used for project planning than asking developers for time estimates based on requirements.
Because velocity correlates to a team’s productivity, there is a tendency for managers to try to “goose†the velocity. The technical term for this is a stretch goal. Just like the coach of a sport’s team trying to get the team to play better, I can imagine project managers saying at a team meeting at an iteration boundary, “Come on team – you did 22 points last week, what do you say we try for 25 this week?†This same manager probably buys those motivation posters of eagles soaring and hangs them all around the team room.
The programming team takes pride in their achievements and they also like to see their velocity increasing. They will try to persuade the Customer to give them points for any bit of work they do. I can imagine a developer putting in a few minutes work to change the position of a GUI button on a screen and begging the Customer, “Can I get a point for that?â€
XP teams can become obsessed with their velocity, but increasing velocity isn’t always a good thing. A team can inadvertently become so focused on getting points done that they sometimes forget the real goal – to deliver a quality product.
This became apparent to me recently when I visited a client to see how they were doing in their transition to XP. Their velocity had skyrocketed since I last saw them – and it was definitely not a good thing.
When Object Mentor does an XP transition with a client, we start with our XP Immersion course to get everybody on the same page about what our goals are. Ideally, we use two instructors, one to train the programmers in topics such as Test Driven Development and Refactoring, and the other coach teaches story writing, iteration planning, and release planning to the customer team. We then bring the two groups together for a day and have the customer team drive the programming team on a classroom exercise so everybody can experience how the process works. The instructors then stay and work with the team for a few iterations, coaching them on how to use what they learned in class on their own project.
Such was the case with the client I mentioned earlier. I was working with the programmers and the other coach had the customer team. When it came time to estimate stories, the other coach suggested using an open-ended scale. Where I like to use a scale of 1-5, this team was using a 1-infinity scale. That’s fine, it doesn’t really matter which scale you use, as long as whatever scale you choose is consistent. Stories were estimated according to their relative complexities, iterations were planned, and the programmers started cranking out code. After a few iterations the team’s velocity settled to a value of about 14 points. The team was doing fine and it was time for me to move on and let them do it alone.
When I returned to do a process checkup, their velocity had climbed to 48 points. Wow. This new process must really be resonating with the team. I purposely timed my visit to occur on an iteration boundary and we conducted a retrospection on how well the team was adhering the the XP practices. This turned out to be the bad news.
With a focus on getting more points done, it seemed that the team had abandoned many of the practices. Programmers weren’t pairing, weren’t writing unit tests, and weren’t refactoring their code. Customers were trying to stay ahead of the programmer’s ever increasing productivity abandoned writing automated acceptance tests in FitNesse and were now back to manual testing. I was heartbroken.
Beck teaches that one of the things teams have to do is to adapt the practices to the organization. Perhaps what they were doing was adapting. Adapting to the point that they weren’t even close to doing XP anymore, but adapting nonetheless. I wondered how that was working for them.
I observed the iteration planning meeting for the upcoming iteration and I noticed that all of the user stories were bug fixes from the previous iteration. No new functionality was being added to the application, the team was essentially spinning its wheels. So even though the velocity indicated a very productive team, the actual productivity was essentially zero. There must be a lesson here.
Velocity is what it is. You must take great care when encouraging a team to increase its velocity because you will always get whatever you’re trying to maximize. You have to be careful that you are maximizing the right thing. Want to maximize number of lines of code produced? Well you’re most likely going to get a lot of really crappy code. Want to maximize the number of unit tests that developers write? You’ll get a lot of them, but they’ll probably be worthless. Applying pressure to increase the velocity might make developers to subconsciously inflate their estimates or worse, abandon good development practices in order to get the numbers up.
You Don't Know What You Don't Know Until You Take the Next Step 2
I was teaching our brand new Principles, Patterns, and Practices course recently (http://objectmentor.com/omTraining/course_ood_java_programmers.html) and I was starting the section on The Single Responsibility Principle.
I had this UML class diagram projected on the screen:
Employee
+ calculatePay()
+ save()
+ printReport()
I asked the class, “How many responsibilities does this class have?” Those students who had the courage to answer a question out loud (sadly, a rare subset of students) all mumbled, “Three.” I guess that makes sense, three methods means three responsibilities. My friend and colleague Dean Wampler would call this a first-order answer (he’s a physicist and that’s how he talks ;-) ). The number will increase as we dig into details. I held one finger in the air and said, “It knows the business rules for how to calculate its pay.” I put up a second finger and said, “It knows how to save its fields to some persistence store.”
“I happen to know that you folks use JDBC to talk to your Oracle database.” Another finger for, “It knows the SQL to save its data.” Another finger for, “It knows how to establish a database connection.” My entire hand is held up for, “It knows how to map its fields to SQLStatement parameters.” I start working on my other hand with, “It knows the content of the report.” Another finger for, “It knows the formatting of the report.” If this example was a real class from this company’s code base I knew I’d be taking off my shoes and socks.
Not that my answer was any better than the students’ answer, given the information at hand there can’t be a right answer because I didn’t provide any context for my question. I found our different answers interesting though. This particular company would have a design phase for a project where UML diagrams would be produced and discussed. How can any reviewer know if a class diagram is “rightâ€?
I have this belief (hang-up?) that you don’t really know what you don’t know, until you take the next step and actually use what you currently have. Looking at UML, we can’t really say that it’s going to work or that it satisfies the Principles of Object Oriented Design, until we take the next step, i.e., write some code and see whether it works or not. The devil is in the details and those devilish dirty details just can’t be seen in a picture.
Let’s take a step back. Before there is UML specifying a design, there must have been requirements stating a problem that the design addresses. Have we captured all of the requirements? Are they complete? Are they accurate? Are they unambiguous? How do you know? I believe that you don’t know, and worse, you don’t even know what you don’t know. You don’t know until you take that next step and try to design a solution. It’s only during design that phrases like, “What’s supposed to happen here,” or, “That doesn’t seem to have been addressed in the spec,” are heard. You don’t know what you don’t know until you take that next step.
It is very easy for everybody on a project to believe that they are doing good work and that the project is going according to plan. If we don’t know what we don’t know, it’s hard to know if we’re on the right track. During requirements gathering, business analysts can crank out user stories, use cases, functional requirements, or whatever artifacts the process du jour dictates they produce. Meetings can be scheduled and documents can be approved once every last detail has been captured, discussed to death, and revised to everybody’s liking. Unfortunately, until solutions for these requirements are designed, they are but a dream. There is no way to predict how long implementation will take so project plans are really interpretations of dreams.
The same danger exists during design. Architects can be cranking out UML class diagrams, sequence diagrams, and state transition diagrams. Abstractions are captured, Design Patterns are applied, and the size of the project documentation archive grows. Good work must be happening. But are the abstractions “rightâ€? Can the code be made to do what our diagrams require? Is the design flexible, maintainable, extensible, testable (add a few more of your favorite -able’s)? You just don’t know.
The problem with Waterfall, or at least the problem with the way most companies implement it, is that there either isn’t a feedback mechanism or the feedback loop is way too long. Projects are divided into phases and people feel that they aren’t allowed to take that crucial next step because the next step isn’t scheduled until next quarter on somebody’s PERT chart. If you don’t know what you don’t know until you use what you currently have, and the process doesn’t allow you to take the next step (more likely somebody’s interpretation of the process doesn’t let you take the next step), then we don’t have a very efficient process in place.
In order to not delude myself that I am on the right track when in reality I’m heading down a blind alley, I would like to know the error of my ways as quickly as possible. Rapid feedback is a characteristic of all of the Agile methodologies. By learning what’s missing or wrong with what I’m currently doing, I can make corrections before too much time is wasted going in the wrong direction. A short feedback loop minimizes the amount of work that I must throw away and do again.
I’m currently working with a client who wants to adopt Extreme Programming (XP) as their development methodology. What makes this difficult is that they are enhancing legacy code and the project members are geographically distributed. The legacy code aspect means that we have to figure out how we’re going to write tests and hook them into the existing code. The fact that we’re not all sitting in the same room means that we have to have more written documentation. We don’t know the nature of the test points in the system, nor do we know what to document and how much detail to provide in documentation. We can’t rely mostly on verbal communication but we don’t want to go back to writing detailed functional specs either. There are many unknowns and what makes this relevant to this discussion is, we don’t even know all of the unknowns. Rapid feedback has to be our modus operandi.
An XP project is driven by User Stories developed by the Customer Team, composed of Business Analysts and QA people. A User Story, by definition, must be sized so that the developers can complete it within an iteration. I have a sense how much work that I personally can do in a two week iteration, but I’m not the one doing the work and I don’t know how much of an obstacle the existing code is going to be. The Customer Team could go off and blindly write stories, but that would lead to a high probability that we’d have to rewrite, rework, split, and join once the developers saw the stories and gave us their estimates. To minimize the amount of rework, I suggested that the Customer Team write about twenty or so stories and then meet with the developers to go over the stories and allow them to give estimates.
My plan to get a feedback loop going on user story development worked quite well. The Customer Team actually erred on the side of stories that were too small. The developers wanted to put estimates of 0.5 on some of the stories (I have my teams estimate on a scale of 1-5. I’ll write up a blog entry on the estimation process I’ve been using.) so we combined a few of them and rewrote others to tackle a larger scope. We took the next step in our process, learned what we didn’t know, took corrective action, and moved forward.
Writing Customer Acceptance Tests didn’t go quite as smoothly, but it is yet another example of learning what didn’t work and making corrections. I advise my clients to write tests for their business logic and to specifically not write business tests through the user interface. Well guess where a lot of business logic resided – yep, in the user interface. We ran into the situation where the acceptance tests passed, but when the application was actually used through the user interface, it failed to satisfy the requirements. I’m very happy that we had a short feedback loop in place that revealed that our tests weren’t really testing anything interesting before the Customer Team had written too many FitNesse tests and the Development Team had written too many test fixtures.
Feedback is good. Rapid feedback is better. Seek it whenever you can. Learn what you don’t know, make corrections, and proceed.
Teaching an Old Dawg New Tricks 6
I learned something a few weeks ago that has saved me quite a bit of typing. I’m a pretty good typist but I still feel that saving a few seconds here and there pays compound interest when integrated over weeks, months, and a career. I’ve never seen anyone do this before and I get to work with a lot of programmers so I thought I’d share it here.
Joe “J.B.” Rainsberger was in our office a few weeks ago giving some internal training. Joe is the author of JUnit Recipes and if you don’t already own the book, buy two copies – it’s very good. Anyway, Joe was doing a demo for us and I watched how he created objects in Eclipse. If I wanted a new Counter object, for example, I would type:
Counter counter = new Counter();
But Joe would type:
new Counter();
and he then uses Eclipse’s Quick Help (ctrl-1) which offers to either create a local variable or a field in the class. That’s 2 keystrokes if Eclipse does it or 15 if I type it. That’s quite a return on investment in my book.
Try it and see if it makes you go just a little bit faster.
Size Matters 5
Contrary to what you may have heard or what you might like to hear, size really does matter. We programmers must take matters into our own hands and become masters of our domains. Unless we take action, things are just going to get bigger and bigger until we have a real mess on our hands.
I travel a lot and I get to visit a lot of different companies. No matter which industry a company is in or which programming language a team is using, there is one commonality in all of the code that I see – classes are just too damn big and methods are just too damn long. (What did you think I was talking about?)
Way back in the olden days when I had hair on my head, I studied Structured Design. This was where I learned the concept of cohesion. A software module with high cohesiveness was considered a good thing. As I transitioned to Object Oriented Design (still with a full head of hair), I learned Bertrand Meyer’s One Responsibility Rule and later Robert Martin’s Single Responsibility Principle. These latter two concepts restate and reenforce what Larry Constantine said back when Structured Design was in vogue – a module should do one thing and do it very well.
The trouble with this idea of a module (class or method) doing one thing is that it is subjective. What I consider one thing you might consider several things. For example, I might see a method as getting a Customer object out of a database, yet you see it as:
- establishing a connection to the database,
- forming the sql,
- executing the sql, and
- creating and returning a Customer object from what it found in the results of the sql execution.
A guideline that sometimes works when deciding if a module is doing “too much” is simply to describe what it does. If you find yourself using the word “and” in this description (or working really hard to phrase the description in such a way to avoid using “and”), it might be doing too much. Of course you have to adhere to the spirit of the guideline. I can describe the National Air Traffic Control System as “Prevents Collisions”. I didn’t have to use the word “and” once. It doesn’t follow that we can write the entire system as one class with one method – let’s call it main. Or if you program in C#, call it Main.
Uncle Bob presents a different view of “responsibility” in his Agile Software Development book. He promotes a responsibility as a reason to change. If a class has two reasons to change, it has two responsibilities and it might be wise to split the class into it’s two pieces.
This notion of breaking a class into smaller and smaller pieces is exactly opposite to what I learned when I first started studying OO. Way back when I worried about bad-hair days, people believed that a class should encapsulate everything that concerned it. A Customer class would know the business rules of being a Customer as well as how to retrieve itself from the database and display it’s data. That’s a fine idea, provided the database schema never changes, the display never changes, or the business rules never change. If any one of those responsibilities change, we are at a high risk of breaking other things that are coupled to it.
So what’s the real problem? What harm does it do if we go around proudly making our big modules even bigger. Well, I can think of a few problems:
1. Comprehensibility
The bigger a method (or class) is, the harder it is to understand without significant study and effort. I believe that as soon as I have to scroll a method in order to read it, I’m wasting valuable time because the method is doing more than my brain can hold. I often find myself scrolling back because I forgot what scrolled off the top of my window. I know I’m in a minority (considering all the code I’ve seen with massive classes and methods) but I like methods short and sweet.
2. Magnets for change
Massive classes with big methods do a lot – they have to because there is a lot of code in them. Unfortunately, that also means there’s a lot that can go wrong in them. When we fix a bug in one of these huge modules, we have to change the code – and changing code often means the code becomes worse. When we have to add additional functionality, the hooks seem to be in these big classes, so they get even bigger, and once again the code deteriorates even more. It’s easier to add code to existing classes and methods than it is to create new classes. Some companies have a heavy hand on the source code repositories and developers would rather make existing classes bigger than deal with the bureaucracy of adding another module to the corporate SCR.
3. Collisions
Because a lot of code is in each of the ever-growing modules, it stands to reason that different team members will be editing the code in these modules for different reasons. You know what that means come check-in time; the dreaded diff and merge. And because it’s so painful, developers put it off as long as possible which only makes the problem worse.
4. Lack of reuse
The bigger a module is, the less likely it is that you will be able to reuse it in a different context. It does so much that it becomes specialized to the current context.
5. Comments are needed
Large methods can’t be named for their intent, i.e., you can’t tell what a method does from its name because it does so much. Earlier this year I saw a multi-thousand line method named ‘execute’. Yeah, it was obvious what it did – not. Developers tend to write comments to explain what a method does. We’ve all seen them – the next 200 lines calculate a thingamabob, then another comment explaining the next 450 lines. The problem with comments is that in large systems, worked on by numerous developers over a period of years, the code goes one way and the comments tend to stay as originally written. When the code says one thing and the comments say another, which will you believe? Yet more obscurity.
6. Decreased code quality
Where do you think you’ll spot a glaring defect quicker, in a 6 line method or in the middle of a 300 line while loop with page-long if-else constructs in it?
7. Increased maintenance costs
Every time you visit a large module, you have to understand the piece that you’re going to work on. Often, that means you have to understand the entire module just to find the area where you are going to work. All of this takes time, and time is money. Ha – I seem to be on a roll with these sayings – “time is money”, “size matters”, hmmmm…. can “your check is in the mail” be far behind?
8. Easier performance profiling
When you are trying to locate performance bottle-necks, and whatever tool or timing mechanism you’re using tells you that the 8,000 line doItToIt() method is taking “too long”, how are you going to find where all the time is spent? It would be much easier to see the 6 line calculateAmount() function was taking too long because it was hitting the database.
There are many things in life that I wish were bigger—lots bigger (hard disk, thumb drive, monitor, RAM, etc.) but classes and methods should not be in that list. Understanding at a glance with good, meaningful, intention revealing names can go a long way to keeping software costs down and making our lives as developers better. I know, it isn’t easy to spare the time. It’s much easier to use that time to struggle to squeeze another clause to that already overgrown method; it’s much easier to use that time single stepping through the vastly indented forest of if/else/for/while; it’s much easier to use that time poring through a tangled and twisted rat’s nest of code over and over just to work out what it might just be doing. Oh yes, it’s MUCH easier.