Design walkthroughs

Interested in knowing about another way to improve your software quality? This post from Project Smart captures some best practices for design walkthroughs. Although written with designers in mind, design walkthroughs of this type can work equally well for small teams of developers, particularly when making changes to mature, well-established software systems.

By scheduling a design walkthrough for a significant change to the application, be it an enhancement or a major bug fix, a design walkthrough enables the developer to get more eyes looking at the proposed change. By catching design oversights early in the process, it can reduce rework and frustration for the developer, and improve code stability and maintainability in the long-term for the entire team. It also has the benefit of exposing more members of the team to more of the code base.

Working as a senior developer for a small but effective software development team in the ’90s, we countered some quality issues in our software by implementing both design and implementation walkthroughs. The sequence of steps looked something like this:

1. A developer investigates the change required, and comes up with a design for the change – the existing classes involved, the refactoring required, any new interfaces or classes required, and so on.
2. The developer prepares a 20-min overview of the proposed changes and their impact on the current code base.
3. A design walkthrough occurs wherein the developer presents the overview and receives the feedback of the team
4. With the feedback in hand, the developer makes the change, noting where the implementation varies from the proposed changes as they work through any unanticipated changes required as they go
5. An implementation walkthrough is held when the change is complete, which provides the developer and the team a chance to review the change, and to understand any differences between the original change discussed and the implementation delivered in the end.

In this way, working with both a design and implementation walkthrough, a team can make best efforts to “plan-do-check-act” on significant changes to the system, and enhance the long-term viability of the application code base.

Enhancing “the flow” of development

Pawel hits the nail on the head with this post on helping a development team as a project manager. It’s not just about getting out of the way and letting the dev team get on with their work. It’s about actively clearing the way for them, freeing them to do what they do best. It’s about helping them maintain “the flow” of problem-solving and creativity that goes into creating good (if not great) software. To do that well is a balancing act for the project manager. On the one hand, you must buffer the team from the worst distractions and time-consuming tasks tangential to their core work. On the other hand, you have to be careful not to filter so much that they’re not connecting well with other departments, or product owners, or users. 

However, I’m not sure that I agree with Pawel when he says that “if they end up helping you with project management, something is wrong”. That seems a bit too black-and-white in judgement. Often team members may see a risk or issue upcoming, or question the schedule, or another department’s estimates, and their feedback is valuable and noteworthy. Is that “helping you with project management”? I believe it is – and it’s all good. I believe what Pawel is getting at is that, taken to an extreme, asking the dev team to do core PM work, and vice-versa, is counter-productive. Far be it for the project managemer to believe that their role should include coming up with extensive test cases, or coding up a Silverlight application, or designing APIs.

Recent thoughts on Scrum

In a recent discussion with a seasoned veteran in the project management field, I brought up my recent participation in a Certified ScrumMaster workshop. He asked me what I had found of interest in the workshop material.

One interesting item that had come up in the workshop was that there should be no time limits on scrum planning (aka Sprint 0) – within reason. Obviously there should be a balance struck between scrum planning and the team beginning to build product. However, I chuckled when I heard “no time limits” because in a previous position we were informed by the CTO that Sprint 0 should take no longer than a week for a 4-to-6 month project – no ifs, ands or buts. I regret not pushing back harder on this mandate – the length of time required for project planning depends on the complexity of the project requirements, the familiarity of the team with the existing product and code base, and the number of inter-departmental dependencies involved in the upcoming deliverables, amongst a host of other variables. At a minimum, we should have been taking 2-3 weeks to plan and design for a project of that length.

Another point of interest in the workshop was on agile estimation, and on the value of relative estimation instead of absolute estimation in a software development project. Apparently, most of us are pretty poor at making absolute estimates (“The church is 4.25 km past the Highway 2 intersection.”) and a lot better at making relative estimates (“The church is next to the Best Western, just down the block from the new organic food store.”) So instead of trying to determine absolute estimates from a development team in sprint planning, the Scrum framework encourages the development of relative estimates – estimating the overall work of a user story relative to the smallest story allocated to the sprint. Once the team has determined which story is the smallest, involving the least amount of overall work, estimating all of the other stories can be done relative to the smallest task. (In an ideal world. I believe that there are limitations to this – wildly different tasks within the sprint may not enable direct comparisons, for example.)

One downside of this approach, however, is that in the Scrum framework the team is then encouraged to arrive at a consensus of overall effort on each user story – even though they likely began with a range of effort estimates. For a given story, the initial estimates might be between 3 and 30 days. After some further discussion, perhaps the estimates converge to 8 to 15 days. Although some would suggest that the average be used, or that the team continue to discuss the requirements to arrive at a tighter estimate, I believe there is value in those numbers as they stand. Take the range given and plug the range into your schedule and estimation tools. Perhaps use the same tools provided in the Scrum framework to help your team arrive at three numbers (pessimistic, most likely and optimistic) for each user story instead of one number, and then apply PERT analysis on those three. Chances are your schedules will be more realistic as a result. 

Recognize that the quality of a relative estimate is probably better than an absolute estimate, and that a range estimate is always better than an absolute estimate.

What do you think? What have been your positive and negative experiences with software project estimation, and Scrum?

What’s your passion?

Passion | ManagerTools.com

This post on the Manager Tools blog caught my attention because it deals with one of my favourite interview questions – “So what’s your passion? What are you passionate about? What gets you sparked and out of bed on a good day?”

Years ago, when I was joining a small firm here in Calgary, one of the principals asked me the same question. He wasn’t interested in my answer so much as he was trying to see how I would light up and spark on something – it didn’t matter what it was. I took that to heart, and when hiring for a development team in later years, I’ve tried my best to ask the question, and to hire passionate people. 

Some were passionate about their family, others were passionate about their hobbies or sports pursuits, one was passionate about wine, another was passionate about travelling. And yes, some were passionate about their work, about coding or testing or designing or planning. It matters less to you that your team is passionate about work, it only matters that they’re passionate about something in their lives. That’s because, chances are, if they’re fired up and passionate about one thing, you can probably get them fired up and passionate about the project.

Look for passion in your hires – try to see the spark in their eye, the rapid-fire speech, the heightened intensity, when they talk about something of interest to them. Get them talking about their interests, and you’ll see it.

Better Projects: Agile or Plan Driven?

Craig Brown at Better Projects posted on Boehm and Turner’s earlier writing on balancing agility and discipline today. Which reminded me – there are two papers by Boehm and Turner on this topic, both of which make interesting further reading to Craig’s post. The two papers, if you want to know more, but don’t wish to read the entire book, can be found here and here.

I found interesting reading in the two papers. However, I wondered whether the balance is more truly between agility and predictability rather than agility and discipline. The agile toolkit can still be applied with discipline, but the outcomes may be less predictable.

Developer testing is not enough

Collaborative Software Testing: Testing is Overrated.

Jonathan stumbled upon this presentation, and he was right to blog on it – it’s an excellent summation of why development teams should not rely upon unit tests alone. In reading the comments and slides of Luke Franci, I was dumbfounded that a team would rely entirely on unit tests before releasing software – no wonder so many software projects don’t meet expectations. Obviously the appropriate blend of code reviews, unit testing, manual testing, usability and acceptance tests is required because, as Luke points out, “no single technique is effective at detecting all defects.” As he says “this is just the start” – I would add to the list performance and scability design and testing, and user acceptance testing by a product champion or selected key users.

It was good to see code reviews listed as an element of Luke’s presentation – these can take various forms and, in my experience, can prove invaluable for catching design flaws and performance issues early in the game. Whether it’s a design or implementation review with peers, or one-on-one “pair reviewing”, or line-by-line peer reviews over pizza, however your team wishes to build code reviews into the development process, it’s a wise investment in their skills and in the code base.

Building a great programming career

http://www.stellman-greene.com/2008/10/23/building-a-great-programming-career/

This caught my eye when I was busy but scanning through my RSS feeds. Later on when I had more time, I went back to give it a full read.

I thought of a couple of things to add – based upon a similar conversation I had with my good friend Predrag Stanar last year.

Learn how to debug code – not just about logging and breakpoints and watch variables, but about how to eliminate potential contributing factors and isolate the bug until it just can’t escape your scrutiny. Sometimes a bug is obvious, more often than not it requires diligent effort to isolate it to a particular method or perhaps even a few lines of code. Come up with your own style of breaking down problems into smaller units – it’ll make debugging much easier.

Learn early on about refactoring and unit testing, in whatever order you choose. Refactoring can be a joy if it’s done regularly and consistently – left to its own devices, a unit of code can get pretty grungy over time with multiple contributors without some regular analysis and cleanup. Excellent tools like JetBrains ReSharper should be in your hip pocket on all jobs – in fact, I recommend you have your own personal copy, it’s that good. For C# projects, the combination of ReSharper and NUnit can save a huge effort in testing and debugging code before release.

At all times look for ways to configure your application from the outside, consider how you can design your code to always run with external configuration files. This will make supporting and maintaining your commercial application far easier – simple XML or text configuration files can be easily maintained and adjusted on site at clients by skilled client-facing staff or support technicians. Think in design not just about skinning the application in this way, but about how to adjust the guts of the code from the outside. Your testers will appreciate it as well, since it will make their testing (manual or automated) considerably easier than having to recreate build after build to adjust the application behaviour.

Consciously selecting a lifecycle or combining lifecycles

http://www.jrothman.com/Papers/Cutter/whatlifecycle.html

I’ve been following the writings and thoughts of Johanna Rothman since my colleague Jonathan Kohl recommended her writings to me. Earlier this year, I came upon this well-written summary of software development lifecycles on Johanna’s site.

In particular, I liked that she emphasized how different lifecycles can be combined depending upon the team, the project, the stakeholders, the requirements, and so on. In my experience, the most effective teams don’t rely upon one methodology or one published lifecycle – they continuously evaluate what’s working for them and what isn’t, and seek to improve their development process by using part of a given lifecycle such as Agile or Scrum.

So have a read through the following article, and don’t get stuck on one lifecycle or another – remember that each has its merits and that you can meld them together picking the best tools from each one for your project.

Excellent thoughts on Agile development

There are some interesting thoughts on agile development in this article by Steve McConnell that echo some of the issues I’ve seen over the years developing with iterative development. 

http://forums.construx.com/blogs/stevemcc/archive/2008/07/29/agile-software-business-impact-and-business-benefits.aspx

Some extracted quotes below that struck a chord with me when I was reading:

“In particular, XP’s emphasis on defining requirements only one iteration at a time didn’t provide for an overall product vision (aka roadmap, aka product definition) that would result in a compelling product.”

“The more time goes by, the less useful the Agile buzzword becomes and the more meaningful it is to discuss specific practices instead.”

“… a product development initiative involving a technical staff of about 200 people. The development team followed XP closely … Development went on for about two years.” [MH: Yikes, XP with 200 people - NOT.]

“In many cases, Agile development practices can help companies raise the bar on their software development efforts. By focusing on business needs first, and technical solutions second, companies can avoid Agile becoming the proverbial ’solution in search of a problem.’”

“The biggest lesson I’ve taken away from the development of Agile methods is that there is no One True Way for software development — and that means teams have to be always assessing their own processes and adjusting them as time goes by. There’s just no substitute for people paying attention to what’s happening around them.”

“Commercial product development needs a strong driving vision …”

One look at the early days of computing

If you’re interested in the early days of computing, or just want to ground yourself in how fantastic (in the true sense of the word) all of our current technology is, watch George Dyson’s TED presentation at http://www.ted.com/talks/view/id/278.

I often marvel at how much technology has developed around us within our lifetimes. When watching this TED presentation, I was struck that the timing of the work at Princeton was just before my parents emigrated to Canada a little over 50 years ago.

For fun sometimes, try this: Imagine being put to sleep 30 years ago, and waking up today to see and hear about our current technological wonders. Think of all of the physical gizmos that would be completely and utterly foreign to you. It’s astonishing.