I wrote the following prose in preparation for my fireside keynote at Concept Camp 2009. Concept Camp arrived at a time when I was asking questions about the software I’ve created over the years. I was wondering if the software I’ve created is truly successful, and how you measure success in software development.
I’ve written commercial software for many companies over the years. Some of the best software I’ve created was for companies that are now out of business. Was the software a failure? Some of the worst software I’ve created, as a developer working alone and just out of school, is still running inside laboratory instruments around the world. Is that software a success?
Athletes declare victory and defeat using scoreboards and finish lines, but success – real success, isn’t easy to measure in software development, or in other lines of work. As an example, let me tell you the story of two men working as army generals, and you try to decide which one achieved victory.
Concept Camp 2009 took place just outside the town of Williamsport, Maryland, which is near my hometown of Hagerstown, MD. Since I grew up in this area I had no choice but to learn about the local history, and there is no shortage of history in the area. For instance, Williamsport, holding a prime location along the Potomac River, was one considered by George Washington as the site for our nation’s capital.
Not far from Williamsport is the town of Sharpsburg. Its 700 residents live next to the Antietam Battlefield – one of the most famous battlefields on American soil. 147 years before Concept Camp, this area was full of soldiers fighting the American Civil War. The general leading the Confederate army from the south was General Robert E. Lee. The General leading the Union army from the north was General George B. McClellan. Both generals were graduates of West Point, but the two applied vastly different strategies in battle.
General Lee assumed control of the Confederate army in the spring of 1862. This was during a time when many felt the war would be over quickly. The Union had already invaded the south and the army was sitting outside the capital city of Richmond, VA. Lee quickly won a series of battles, however, and pushed the Union army away. Those battles ended the hope for a quick end to the war.
The situation was beginning to worry President Abraham Lincoln. European powers like Britain and France were watching the rebel army effectively defend its territory, and they were thinking of supporting the south’s claim for sovereignty. Meanwhile, mid-term congressional elections were coming up in November, and if the northern voters perceived the war as going badly, their voting power could end Lincoln’s plan to reunite the country.
Against this backdrop, General Lee saw an opportunity for great military and political gains. In early September, he led his army north across the Potomac River. It was the Confederate army’s first steps on Union soil.
General McClellan chased Lee’s army until they met outside of Sharpsburg by the Antietam Creek. The ensuing battle on September 17, 1862 was horrific. It is still the bloodiest day in American history with 23,000 casualties. You can read about the terrible fighting around Miller’s cornfield, Bloody Lane, and Burnside’s bridge in books like “Antietam - A Soldier’s Battle” by John Priest (my history teacher in school).
McClellan’s army left 30% of Lee’s army dead or wounded. Because of the casualties, Lee had to withdraw his army and return south to Virginia. President Abraham Lincoln took this opportunity to issue the first Emancipation Proclamation on September 22nd. The Proclamation meant the war was no longer just a war between states, but a war to end slavery. The higher cause boosted the morale of the Union soldiers and bolstered support for the war from voters. Overseas, the Proclamation forced European powers to reconsider support for the rebel states, as they didn’t want the world to perceive their policies as supporting a slave nation.
Doesn’t this sound like a decisive victory for McClellan and the Union?
Of course, I didn’t give you all the information you needed to know about the battle. I didn’t mention that McClellan’s army outnumbered Lee’s army almost 2:1 (90,000 men to 50,000 men). I didn’t mention that McClellan kept half his men in reserve – they never fired a shot. I also didn’t mention that McClellan split up his attacks into three separate assaults, giving Lee time to shift and reorganize his defenses. And I didn’t mention how vulnerable Lee’s position was with his back to the Potomac River.
Finally, I didn’t mention that President Lincoln, unhappy with McClellan’s performance, removed the general of his command not long after the battle.
Most experts believe McClellan had the opportunity and resources to eliminate Lee’s army and put an end to the war. Instead, the civil war continued for three more years.
It’s difficult to draw analogies between war and software development. One is a bloody endeavor that kills while leaving physical and mental scars. Another is a profession that involves keyboards and cubicles under fluorescent lighting. Nevertheless, I think there is something we can learn about victory from the Battle at Antietam. Achieving victory doesn't mean we've achieved our full potential.
Also, we already know that victory is hard to define. Shipping a product isn’t a reason to declare victory, particularly if the product falls apart after 1 month. We can’t declare victory based on the number of lines of code we’ve written, or the number of features we’ve shipped. Having too much code or too many features can lead to defeat. We can’t declare victory based on the number of unit tests we have, or code coverage statistics. We can’t declare victory by pushing cards across a Kanban or moving a line down a burn down chart.
All of the things I’ve mentioned are indicators of success, but even if we look at them collectively we’d still be missing the judgment of the people who use our software. Does it have the right features? Is it fast enough? Is it friendly? Does it work without unnecessary surprises? Did it reach on time? Did it cost too much?
Customers, clients, consumers, and users all have a considerable say in our success and failure, and we can’t ask their opinion using only a single point in time, just like we can’t declare the winner of a 100 meter dash by observing runners at the 50 meter mark. Most applications need to evolve over the course of years, and we can only achieve victory if we continue to grow the application.
Returning to a military theme, there is the type of victory known as a pyrrhic victory. A pyrrhic victory is what happens when you are decidedly victorious in a single battle, but paid such a heavy price to win that you are in a position to lose the war. Not everyone realizes that software development is a marathon, and shortcuts often lead to pyrrhic victories. The application ships, but it’s an un-maintainable collection of shortsighted hacks that will fail to evolve with the user’s needs in the future.
Since users have a considerable vote in our quest for success, having them invested in our software project is a great idea. The good news is that software development is making concerted efforts to move the user closer to the center of our development activities.
We started by changing our methodologies. We realized that a waterfall process, where the user tells us in detail what they want, and then we hide in offices for 24 months while building it, results in defeat for everyone involved. We started to adopt agile methods that embrace change and require everyday participation from the users.
We also started moving users closer to our code. Doman driven design encourages the use of a ubiquitous language that the developer and the business expert share, and the language influences the names of our abstractions. We strive to write acceptance tests using natural languages a customer can understand. Everyone wants a domain specific language that a business expert can comprehend.
We’ve moved our users closer to what we do, but software development is still not centered around the user. Developers sit in the center of software development as the sun sits in the center of our solar system. We use our heavy mass of technology to distort light, space, and time to our needs. We tell the user what can and can’t be done. We’ve trained them to come to us and ask us what’s possible, instead of envisioning their own possibilities.
Like General McClellan in the Battle of Antietam, we aren’t reaching our full potential.
General McClellan didn’t fight to win the Battle of Antietam – he fought not to lose. He was cautious. He was pessimistic. He didn’t pursue Lee’s weary army as they hobbled back into Virginia, though he had fresh regiments of soldiers available. McClellan saw only risks, and not the opportunities.
Software developers are obsessed with mitigating risk. All the indicators of success we talked about earlier- deadlines, code coverage, unit tests, burn down charts – these are all in place to mitigate risk. We also mitigate risk with compilers, coding standards, source control systems, patterns, practices, daily stand up meetings, continuous integration builds, and more.
Avoiding disaster in software development requires an obsessive-compulsive approach to risk management. We focus on risk instead of potential.
Our focus means we don’t fight to win in software development. We fight not to lose.
Once a customer asked me how I could automatically populate one of the screens in her application with information held inside a database of manuscripts. I immediately saw the risk in matching data to the right fields based on the context of the screen. I’d need a way to search and index the correct pieces of information. I’d need some fuzzy logic to interpret the meaning of the data. There would be some advanced algorithms needed to transform and pick apart the appropriate information.
I wasn’t thinking of the software’s potential. I wasn’t thinking about how this feature could transform the lives of the people who used the software. I saw only the risks. I surrendered to fear.
Kent Beck listed courage as one of the primary values to embrace in his Extreme Programming book. We’ve made significant advances in embracing many of the other values listed in the book. We practice test-driven development while reciting the Single Responsibility Principle in homage to the value of simplicity. We hold daily stand up meetings and apply continuous integration to promote the value of feedback.
But courage?
It’s difficult to find a pattern or a process that helps us practice courage on a daily basis.
How many times have you seen a software team talk a customer out of a feature because it might require something different, or unknown?
Fear of the unknown drives too many decisions in software development.
The next time your user asks for something and your first impulse is to start assessing the risks involved – STOP.
Think about the possibilities first. Think about the value to the user. Could this request make the software great? If not, how could it be even better? What can you do in this area to empower the user? How can the software truly transform their job, or their business? What could you change about your technology to make this work? What could you change about your team to make this work? What could you change about your company to make this work? How many days would you really need to experiment with something new and different? Only after you understand the true potential of what is possible can you can put on your engineering hat and assess the risks.
We all work with limited resources and deadlines, but we often use these constraints as excuses instead of parameters in a formula for victory.
Only courage allows us to find the true potential of software. Only courage allows us to recognize our weaknesses and try something new. Only courage allows us to explore unfamiliar landscapes in the world of software development.Only courage will allow us to align our goals with the goals of the user, make our software great, and give us a shot at undisputed victory.
--
I want to say thanks to @SaraJChipps for having the courage to organize this novel event, and inviting me to speak. And thanks to everyone who had the courage to come and share their stories and laugh in the rain. Concept Camp 2009 was a success, and I can’t wait for the next one! I just hope the weather is a little better …
OdeToCode by K. Scott Allen
Subscribe
Twitter
Search
About
Learn C#