Code Reviews - Systematic Collaboration January 30, 2009
Posted by Allen Manning in : Process , 1 comment so farThe important point here is that adopting a trivial process or system can produce dramatic results. Once your grasp this concept and learn to apply it to your software projects, you can truly claim that you are working smart, not hard, and you can come that much closer to hitting your deadlines without the long hours and daily stress that seem to afflict so many software projects today.
Steve Maguire, "Debugging the Development Process"
Systematic
Steve Maguire is right, one of the keys to becoming a more efficient development team is to work systematically- devise automatic systems that ensure quality, and increase velocity.
The key with systematic, is in being automatic.
A professional soccer player who’s ability to trap a ball automatically lets her think about where she is going to pass it while it is in the air, rather than concerning herself with how she is going to gain control.
In our sport, the automatic systems we have in place frees up our mental space to worry about the hard problems- improved performance comes from a development a form of ‘body memory’.
Collaboration
Collaboration is key. The software we write is a multi-dimensional collaboration between us, our colleagues, and our customers.
Supportability
With our colleagues, we need to communicate ideas and support each other in solving difficult problems. As much as we may like to think so, there are no super-developers who have no need to collaborate with other developers and are islands unto themselves. Even if there were, we would want these Übermensch to go on vacation to cool down their mega-brains wouldn’t we?
Who supports their code when they are on vacation?
The key here is that our code must be both correct and supportable. Our colleagues must understand more of the system than just those areas they developed.
By collaborating and reviewing each other’s code we can detect stylistic differences and areas that need refactoring. Ideally, all code in an organization should follow a style guide and look relatively the same. When we review each other’s code, it should look like something we could have written.
You know if you are doing this right if after opening a particular class, you can’t tell who on the development team is the author. Stylistically it looks just like something that you or one of your colleagues developed.
This goes back to being ‘systematic’, rather than be distracted by the stylistic differences of the coding style, we should be able to concentrate on the problem at hand.
Defects
The cost of fixing defects increases with time, and exposure. The longer a defect exists in the software the more expensive it is to fix, and the higher the potential cost; by collaborating with each other and looking at each other’s code we find defects earlier in the process.
Knowing when we are Done
As mentioned before, there is no objective criteria to tell us when we are Done. Rather, we need our community to help evaluate when we have achieved Doneness. Code Reviews are a very contextual way for us to see exactly what is or isn’t Done and have the necessary discussions and debates needed to get us all on the same page.
Code Reviews
We can see why we need to collaborate and how working more systematically makes us more effective. By putting this together we find ourselves incorporating Code Reviews as a regular part of our development process.
There are plenty of tools for doing code reviews, and also some strong industry arguments for the benefits. Let’s focus on some practical advice for adding this to our regular daily workflow:
Review every changelist
Rather than the author deciding if a changelist is worthy of review, let the reviewer decide. The reviewer, more likely than not, is going to be the one supporting it so let him make that call.
It also removes the decision making process from the whole equation, there will be no time spent deciding on a criterion of ‘important’. Rather, trivial reviews will just be conducted more quickly.
Let the same reviewer re-review
If a reviewer suggests that some code needs to be changed, and the author makes some changes, then the reviewer should review those changes. This should continue for all follow-on changes.
This is a clean and systematic way for the reviewer to know what work has actually been done: If they don’t get any follow-on reviews then it can be assumed that no further work has been done.
Rather than define a system for what suggestions must be implemented, and which ones are ‘nice-to-haves’, it is lighter-weight to just have an ongoing dialog between reviewer and author.
Reduce friction by using a good reviewing tool
Rather than emailing to reviewers a diff or a changelist ID, use a Code Review tool that helps automate this process. This reduces the ongoing burden of looking up a particular change or navigating various tools to gain more context.
Crucible is a fantastic tool for facilitating code reviews, but there are many others worth evaluating.
Agile Designer / Developer collaboration with Scrum September 12, 2008
Posted by Allen Manning in : Process , 1 comment so farOne of the biggest challenges for us moving away from an up-front design approach to a Agile / Scrum approach is figuring out the best way to incorporate the work of our visual designers into the collaboration.
We want designers to join in with the ongoing design and development in a way not too dissimilar to another developer (or developers joining as another designer). In order to do that we need to avoid the perils of: excess inventory, feature creep, and ‘throwing pixel tweaks across the wall’.
We will walk through a few techniques to help keep the process lean and the collaboration flowing organically.
Traditional Designer / Developer collaboration using mock-ups
Traditionally, designers will create mock-ups representing how the application’s UI will look at some point in the future. This work may be the culmination of wire frames, user testing, and several other forms for UX design methodologies. It may also involve developers during the early preparation.
Design mock-ups can take many forms. These mock-ups may be fully designed images that will be used for later pixel-perfect comparison. They may also be static HTML pages that will need to be made dynamic and integrated into the build. They may contain ‘nice to have’ features which can be used to discuss with developers and see what can fit into the current iteration. These mock-ups may be formal: used as a way to define a commitment of work, or they may be loose artifacts for idea generation and sizing of a project.
It may be blurry to a developer exactly what they represent- what are they signing up for?
Traditionally, there is an up front exchange between a designer and a developer where the developer gives estimates as to how long a particular design will take. There may be a couple of iterations in the mock-up to accommodate the feedback of the developer. After the developer agrees to a particular design, the design can be considered “signed off” and then is handed off to the developer for implementation as a prototype.
After the design is implemented, the designer reviews the prototype and creates notes on how the implementation needs to change to more closely match the intention of the design. This may take many forms, but commonly a list of changes is presented to the developer- moving pixels to match the original design, changes to the design based upon recent discoveries, etc.
Wash, rinse, repeat until the design is considered fully implemented, or Done from the designers perspective.
A project manager helps facilitate the collaboration between designers and developers and guides the business decision making.
Challenges with the Traditional Approach
There are a few issues with this traditional designer / developer collaboration that can hamper open collaboration and slow down team velocity.
Change Management
If there aren’t some clear rules defined in the Planning Game, then feature and scope creep can easily swerve a software project off into a ditch of “interesting ideas to try out” and “hidden assumptions”.
Developers are placed in the position to constantly push back on new cool ideas because they are out of scope of what was originally agreed. If the developer is the only one that is pushing back, or it taking the overall team resources into consideration, then there will be some real problems.
Developers traditionally, don’t enjoy negotiating and estimating as much as building cool features. Additionally, there is an overall industry trend for under estimation.
But the software does not have a neutral estimation problem. The industry data shows clearly that the software industry has an underestimating problem.
Steve McConnell, “Software Estimation, Demystifying the Black Art“
It is risky to put the burden of change control solely onto the shoulders of the developers. Bringing in a project manager for arbitration isn’t the leanest approach either- it quickly grows into a negotiation game, when really developers and designers should just be ‘jamming’ together.
Pixel tweaking across the wall
We can also find ourselves in a situation where mockups are emailed repeatedly to developers with little pixel tweak suggestions and other design notes (i.e. “please move this button 5px to the right and make it 10pt Verdana”). It may look ‘good enough’ to the developer, but doesn’t match the quality that the designer is expecting.
Some of these notes may include work that would put the estimates at risk. All of this needs to be communicated back to the designer.
The developer may attempt to fix many of the design problems only to see that more issues introduced that the developer didn’t notice. The designer will then put together another set of notes, and that set of notes will need to be communicated again, with an additional round of estimate negotiation.
If sent ‘across the wall’ in this manner through indirect communication this can take a significant amount of time and can be quite inefficient. It is also at such a level of technical minutiae that a project manager would prefer to be left out of as much of this communication as possible.
Making this back and forth too formal can also hamper the creativity and spontaneity of the process as a whole.
Excess Inventory
This is a core Scrum concept: don’t create excess inventory. There is a metaphor here between product inventory from a factory and artifacts created during the software development process. A factory will be less profitable if it creates more products than can be sold- the excess inventory will need to be stored and then eventually disposed of by some means. There was cost in creating it and cost in disposing of it, but no revenue from selling it.
Unused feature ideas in final mock-ups are excess inventory or team over stock.
This isn’t to say that the iterative design process of auditioning many several ideas to arrive at a final proposal is excess inventory. Rather, all of the feature ideas that will most probably not make it into the iteration are excess inventory.
An unused screen or an idea which is not part of the story that the team is currently working on will need to be explained, estimated, and then eventually rejected. There is a cost to the entire team to go through that process of negotiating a tangential feature idea out of the mock-up.
Sometimes this is unavoidable, but it should be considered an expense that the team should work on reducing.
Techniques to facilitate agile designer / developer collaboration
What we want to do is create lean process where designers and developers can collaborate together focused on only those stories that the team signed up for during the iteration without the overheads of game playing and negotiation of project constraints. We want to keep the process lean and focused. Below are a few techniques we have started using to help us move in this direction.
Technique 1: The “no excess inventory” final mock-up
As described above, we want to remove overheads associated with excess feature inventory in our mock-ups. Right after the Sprint (iteration) begins a designer on the Scrum team should create a final mock-up representing the features that the team signed up for during the sprint but no others.
No speculative ‘nice to have’ features should be included.
This represents a great communication tool for the team itself and between teams. It basically says, “By Sprint’s End the software is going to look like this- no more, no less”.
The team should also carefully consider if the mock-up should be updated once the software has been partially implemented. Each update of the mock-up runs the risk of being excess inventory unless it can be argued that the communication the updated mock-up yields offsets the development cost.
It is often much more efficient to just refer to the current state of the daily build. This is also a strong argument for first implementing a non-functional visual prototype to move the team away from the mock-up.
Technique 2: Time boxed paired development
During kickoff, for each story involving UI development, reserve some Timeboxed tasks for a developer and designer to try out different ideas while sitting together. This can be considered the equivalent of ‘paired programming’ but for interactive design.
Because it is Timeboxed, it forces both the designer and developer to make choices as to what design tweaks should be worked on. Designers will need to account for the actual time it takes developers to implement features by sitting along side and seeing the build compile and seeing the nuances of getting the layout right.
I don’t think that this is the most efficient technique for the initial development of the view, but rather enhancing the base visual prototype. It is a smart technique in facilitating the collaboration between designers and developers without the overheads of traditional change management.
If there is a risky idea to try out, they can prototype together and see how far they can get in the reserved time.
If the pair gets to the final hour, the focus on what they are jamming on will be quite clear if they know that after that hour, it will be shipped as is. They are both responsible for it.
Technique 3: Replace “Pixel tweaking across the wall” with Timeboxed paired development
Use the Timebox paired development mentioned above for “pixel tweaking” notes. Rather than emailing several rounds of design notes, developers should sit alongside the designer that has an ordered backlog of design notes.
The most important design tweaks will get done first, and when the reserved time is complete no more design tweaks get in. If all the notes have been completed and there is still time remaining, then free-form collaboration can happen to just try out some ideas.
What typically happens is that designers can see for themselves those little changes that seem like they should be simple but are in fact time consuming to implement. On the flip side, the pair may find that they were able to breeze by something that might have seem complicated. The designer, being aware of the time remaining in the session, can then direct the developer to work on other “low hanging fruit” that will have a higher likelihood of getting fixed.