In Search Of

Perhaps you have experienced the struggles of on-boarding new developers into an already large team in the middle of a project. Everybody who comes wants to have a say in how things are done, no matter how late in the process they get involved. Here is a litany of the types of commentary that I hear in this situation:

• On my last project we used <insert product, pattern, or practice> and it worked great. We should certainly use that here.
• We don't need <insert pattern, product, or practice> its too <insert adjective>.
• Why don't you just <insert suggestion>.
• The code-base is in a bad state because <cite example>.

Each of these commentaries were delivered, without necessarily an understanding of the choices that were made by the team to get to this point, nor with a full understanding of the work remaining. I sincerely believe that each developer made the comments in a spirit of trying to help the team. I also believe that each of these comments reflects the developer trying to construct a "familiar" environment where he knows how to deliver value.

Here are the problems with this:

• Commentary rarely reflects a problem statement before offering a solution.
• Commentary rarely exposes the cost (in effort and risk) of adopting the solution.
• Commentator may or may not have the experience or skill to lead the team through the adoption of the solution.
• Commentator may or may not have thought through the solution to the ultimate conclusion - to determine whether it is feasible, valuable, or reasonable within the context of the project.

I attribute these commentaries to each developer's on-boarding process, and their process of "mourning" the familiarity of their last engagement, while also trying to understand the current environment.

Read the rest of this post »

I am not a fan of software methodologies, third party libraries, hyper-generalized frameworks or other so called productivity enhancers within the software development process. At the same time, I abhor the idea of a thousand developers at a thousand keyboards creating a thousand screens, features, pages and trying somehow to stitch them together into a cohesive software product.

What do I like? Small teams of smart developers who understand how to build small re-usable frameworks to solve problems that they have already solved, and are likely to need solving over and over. Guys and Gals who are likely to re-factor their initial solution into a mini-framework. Sometimes these frameworks "adhere" to each other, and grow into something more comprehensive. Other times they are simple labor saving through code re-use.

Read the rest of this post »

Real World developers prefer:

• Getting things done over sitting in meetings, but understand that communication is important.
• Working code over extensive documentation, but understand that government regulations, and product sustainability require a rational approach to documentation.
• Requirements that describe business value over requirements that prescribe implementation vectors, but understand that the customer often can only express requirements in concrete examples based on his or her experience.
• Practices that work HERE over elaborate methodologies that were designed elsewhere, but understand that some established repeatable practice is beneficial.

Read the rest of this post »

This article by Larry O'Brien got me fired up...

Not because I disagree with the notion of some software developer being 10 times as "fast" delivering software as the average developer. Because that is not what productivity means. Productivity is about leverage, not speed.

Read the rest of this post »

One of the hyped benefits of agile software development practices is increased productivity. It is also the benefit that I am most skeptical of. Software productivity is notoriously difficult to measure. That is because there are no relatively standard units of measurement of output. This is true regardless of whether you are using agile practices or not. In fact, the measurement of software output itself is an expensive activity, so in any normal case study it would be hard to prove. Since books have been written on this topic, I do not feel the need to delve deeper into this topic, except to say that all of the problems described in Fred Brooks' famous Mythical Man Month still exist today, and there has not been a universally adopted solution.

Nevertheless, I am not totally willing to call bullsh*t on the productivity benefit. There are three completely anecdotal reasons for this:

1) Agile practices tend to focus less on documentation and more on producing working software. This leads to spending less time on speculative documentation that ends up being revised many times. Rather than guessing what users want, agile teams build it as quickly as possible, and get feedback, and revise it, until it IS WHAT THE CUSTOMER WANTS! So from a productivity perspective, it is less work to deliver what the customer wants, not what they thought they wanted or what we thought they wanted. Is this real measurable productivity? NO - but it sure as hell feels good to both the developer and the customer.

2) The shorter measurement cycles that agile favors help resources focus on the needful, rather than the fanciful. This means that developers are focused on working in the next feature. Management theories put forth by Elliot Jacques talk about time span - the individuals ability to plan into the future. Developers typically do not a have long time span. I have often experienced developers who became overwhelmed trying to figure out what order to work in, and ended up being unproductive or paralyzed by unscoped tasks. The rhythm of consistent pacing, tends to allow the team to relax around planning, because there are regular intervals of planning activity, broken by longer periods of uninterrupted development. Is this real measurable productivity? NO - but the developers will tell you that they are able to relax and focus on solving technical problems rather than worrying about deadlines and planning.

3) The agile principle YAGNI (Ya Ain't Gonna Need It) reduces the investment in complex architecture, or over-engineered solutions, or premature optimization. The principle is less about improving the productivity of individuals, and more about improving the output of the team. It is a principle that allows the team to hold itself accountable to deliver the smallest, thinnest, cheapest version of each capability, rather than the most ornate, most performant, most scalable, most beautiful version. Agile principles direct us to deliver an acceptable solution with the least effort, rather than an acceptable solution that anticipates all future events. Is this real measurable productivity? NO - but as I learned early in my career - the best way to get more done is to figure out all the things that don't need to be done and not do them.

When I evaluate these reasons, I recognize that the perceived increase in productivity may be much greater than any actual increase, but at the same time, perceived increase in productivity can improve morale and reputation in ways that by themselves lead to real increases in productivity. Agile life cycle projects often feel less like a "death march" than gated life cycle projects, and that alone can lead to increased productivity and motivation.