Images in this post missing? We recently lost them in a site migration. We're working to restore these as you read this. Should you need an image in an emergency, please contact us at imagehelp@codebetter.com
Improving Software Process - A Letter to Upper Management

The following is an email I wrote to the upper management in our company when asked about things we can do to improve the process and what are the next steps of things we need to fix in our application.  It remains mostly unedited and contains my thoughts on what will make our company better when it comes to the software we're writing.  It wasn't written as a blog post.  It wasn't until after I finished with it that I realized that it was decent content for a blog post.  You'll find a very "XP-ish" theme throughout, and that isn't necessarily an accident.  Hope you enjoy! Please leave feedback if something moves you.

Overview

The following contains my thoughts on software development at Super Awesome Company. While I can address the specifics of the project that I see need to be fixed and modified (the “what”), I am instead going to focus on how these items get fixed. I am choosing to do this because over time the new website will have bugs that need to be fixed, enhancements that need to be made, or new features requested. For the long term health of the project it does not matter so much “what” is implemented but rather “how”. For that reason I am avoiding specific project level tasks in this document and speaking at a higher level.

Software has been being developed for over 30 years. While the internet is relatively young, software development by comparison is not. Super Awesome Company will benefit from a commitment to good software development practices. Further, it takes a great deal of commitment and discipline to reap the benefits these practices can bring. Many of my suggestions are based on these principles, which are principles I have committed to learning and adopting over the last several years.

The overarching suggestion I would make is make quality the focus. In order to produce quality, we must slow down. In order to go fast you must go slowly. Sacrificing quality should never be an option. Consider a car manufacturer who needs to get 100 cars built in a single day. If they can only build 80 cars a day, is it better for them in the long run to get 100 cars out the door but have problems or 80 problem free cars? Building deficient cars carries more expense that just fixing the broken cars, such diminished brand reputation. If the goal is 100 cars per day, measures should be sought to increase production while keeping quality high.

We don't need to look too far to see where in a rush we've done something that we've had to revisit several more times because we were "going fast". We've been rushed for nearly a year and I can't say that we are any further along than we would have been had we approached the project more methodically. In some areas we may be further behind where we would have been since we "made sacrifices" to get things done, which have ultimately only put us further behind. Again, to go fast we must go "slow" (methodical). Put another way, quality breeds speed.

Any process, principle, practice we choose should have quality at its heart. Regardless of what process, principles, practices we adopt they will only be successful if we are disciplined enough to follow them.

Planning

Requirements

Requirements need to be clear and understood by all parties. Before developers set out to coding we need to have a clear understanding of what the problem is. The developer is not able to provide a solution until the problem is fully known and understood. Often the perceived solution to a problem is not the best solution. Failure to fully understand the problem/scenario results in rework.

Releases

We need to have planned releases. The timeframe can be discussed and agreed upon by the team. In order to have successful releases we need to plan each release. Each release should be broken down into smaller time frames, iterations. During the iteration the work should be stable for each developer. In other words, they know what they’re going to work on and accomplish (see requirements above) for any given time period.

Metrics

We need to be measuring metrics for the purposes of planning. If we get 10 units of work done each week on average and we have 20 units of work to do, we can easily figure out what is left to do. Without any metrics gathering we can’t do any planning and we’re really flying blind. This will also help with project post mortems. For example, the “web order manager” project was originally estimated to take a week worth of development effort. Three months later, it is still not finished. This is a combination of putting someone with limited knowledge of the business estimating the project, an overly aggressive developer estimate, and having no metric to pull from on how long something should take.

Flexibility

We need to be disciplined in the process of building software, but also realize when the process needs tweaking that we should respond and not be afraid to tweak the process to meet the needs of our team

Design

Simplicity

We should strive for simplicity in our designs. “Clever hacks” are often not healthy for the life time of the project. Simple designs are easier to understand and improve upon. Simple designs also allow other developers ease in working on code. This is much harder to do in practice but it always pays off in the long run.

Design aspects dovetail with testing (later in this document). Typically complex designs prove to be hard to test. When we write code based on simpler designs we’ll find that our code is easier to test. We want both, simple designs and easy-to-test code.

Coding

Standards

We should implement a standard for code development. Right now you can find three different styles/methods of coding in the code base. This makes it hard for developers to work on code they did not author. Projects I work on outside of work require all new code meet the standard, otherwise it is rejected until it meets this standard. As a consumer of these projects I’m always grateful when I can move through any of the project pieces and the code always looks the same.

Testing

Given the environment and complexity of the code, we need to require the developers to be able to test their code in an automated fashion. Visual verification is orders of magnitude slower than automated testing. Once an automated test is written, it runs every time. By having a large collection of tests we can makes changes to certain parts of the application and use existing tests as a safety net to verify nothing else has broken. We currently have over 1,150 tests (about 30% of code has tests) that run whenever someone commits code into source control. Those tests run in about 20 seconds. Imagine how long it would take a user to test each of those cases visually every time a piece of code changes.

Two weeks ago I sat in a meeting adding functionality to shipping and enhancing rules around shipping hazardous items to Canada while people were finding issues because of a solid base of tests. Before the meeting was over both issues discovered were fixed and tests were added for these specific issues so we would be guarded against this happening again.

Unit Tests

All code must have unit tests that can be run in an automated fashion. If the code cannot be unit tested (tested in isolation from other components) it should be restructured in such a way that it can be tested. Very few pieces of code are truly not testable. As such we should have very few areas in our code base which are not tested.

Proving Bug Fixes Through Tests

When bug is found a test should be written before any attempt to fix the bug. This test proves to the developer the bug exists but secondly gives the developer a marker to know when the bug is fixed. As a benefit, this new test acts as a guard against this particular bug ever happening again. This test, when first written, should fail because the developer has not fixed the bug yet. The developer should then work to make the test pass, and by extension fixing the bug. The cost of adding the test is very small when compared against having the test guard against this condition ever happening again.

Code Coverage

We should implement a standard for new code coverage, code that is tested by an automated test. I would recommend somewhere in the 80%-90% range for code coverage. In order to write tests the developers will be forced to think about their code a bit more thoroughly.

Pair Programming

We should adopt pair programming as a method to both increase shared knowledge but also as a means to quality. Pair programming is two developers sitting at one computer for a period of time while code is written. From the outside it may seem impractical to devote two developers to a single computer, thinking it is inefficient. Industry studies however show that code written in a pair has a four-fold benefit:

  1. 15% less code– Studies showed that less code is written in order to implement the same functionality. Less code means less to maintain and understand. Less code is also typically simpler.
  2. Less bugs – Developers, when working in pairs, can catch each other’s bugs before they ever make it to production. We therefore save time that it would take to fix the bugs that would otherwise go undiscovered.
  3. Shared domain knowledge – When “pairing”, each developer is training the other and sharing knowledge and rules around the business. This avoids silos and situations where only one person knows the code.
  4. Increased Skill – When “pairing”, design, coding, and testing techniques are transferred between developers. This is often why many development shops pair their senior developers with junior developers; to raise the skill level of the junior developer.

Collective Code Ownership

No one person should be a silo/bottleneck for any area of the code. Any person should be free to make suggestions, fix bugs, or refactor any part of the code. Pair programming (see above) is one tool which seeks to address this.

Conclusion

While the above recommendations may seem like a lot, the above items all really go hand-in-hand. Consider:

  • Collective Code Ownership is had through Pair Programming
  • Standards are enforced by developers when Pair Programming
  • Writing Unit Tests typically leads to Simple Designs
  • A commitment to Code Coverage leads to more Unit Tests
  • Gathering Metrics leads to better estimates and Release planning

Adopting the above will move us in a positive direction and ensure that all projects coming from our department will be of ever heightening quality. Once the quality bar is set, then we will begin to see the pace pick up; Remember, quality is a prerequisite to speed.


Posted 03-05-2009 12:49 PM by Tim Barcz

[Advertisement]

Comments

Zac wrote re: Improving Software Process - A Letter to Upper Management
on 03-05-2009 2:04 PM

Holy cow man!  Good post!  What was the reaction to this email?  

sergiopereira wrote re: Improving Software Process - A Letter to Upper Management
on 03-05-2009 2:16 PM

Excellent. For a second it seemed like a prayer :) Is that a phone call from upper-management that I hear? Go get them, Tim.

Tim Barcz wrote re: Improving Software Process - A Letter to Upper Management
on 03-05-2009 2:16 PM

I have not yet heard back.....

Am hoping to hear something soon though.

Jak Charlton wrote re: Improving Software Process - A Letter to Upper Management
on 03-05-2009 2:27 PM

Small niggle ... you forgot to mention any direct business benefits ...  which is what management types really want to hear :) Good luck with it .!

Tim Barcz wrote re: Improving Software Process - A Letter to Upper Management
on 03-05-2009 2:32 PM

@Casey

I mention speed and quality, hoping the connection would be made to dollars....think I missed it?

If it were you, what nuggets would you have added.

Michael D. Hall wrote re: Improving Software Process - A Letter to Upper Management
on 03-05-2009 3:32 PM

You have to specifically address the business. How will it make the company more profitable and competitive. I had the opportunity to sit down with the regional chair of a nearly billion dollar company in the most profitable region. And the conversation came down to IT being a cost-center that the company is always trying to minimize, despite the fact that the company was so reliant on tech. Didn't matter, and that is the typical position for all executives, often even if the company is entirely electronic. They don't really care about the code, they can't even conceptualize the systems except in an abstract way. That's not an insult either, it's not their job to, it's your job. If you vcan explain to them how to make more money, then that's a better approach. Show me the ROI!

Tim Barcz wrote re: Improving Software Process - A Letter to Upper Management
on 03-05-2009 3:40 PM

@Michael,

You're probably right....right now I see some areas that could be tidied and streamlined thus saving money.

Maybe not necessarily ROI but definitely relevant is the fact that the new application was a complete ground up rewrite taking about 10 people full time for about a year.  All of that could have been avoided had many of these principles been followed from the outset.  So while the above may not directly relate to ROI it should not be such a huge stretch to see that rework and poor engineering could result in rework....and that means costs and lost ROI from projects you could have been working on.

Mark wrote re: Improving Software Process - A Letter to Upper Management
on 03-05-2009 3:46 PM

I don't work for the company I link to, but I might as well for all intensive purposes and props I send out about its product. ;-) But what I read here is that you need to flexibility to adapt as needs and your processes change, and strong process automation. For example, it's hard to imagine doing daily builds without a good build management system, or continuous integration without strong branching and merging functionality, or common code ownership without full versioning, or short release cycles without strong release management, or finally, test first development without good defect and issue management. Agility is often posed at the opposite of developing with rigorous process. It's not. Agility is really about finding dynamic balance between the needs of the business for visibility, control and accountability and the needs of your development staff for ease of use, flexibility and productivity. As you say, speed kills. XP is certainly one methodology to improve quality and knowledge transfer (think vacation or sick days), but without the proper tools to enable this balance and agility, it may be wasted in meetings and letters. Good luck to you. Can't wait to hear how things turned out.

Mark

Oliver Joest wrote re: Improving Software Process - A Letter to Upper Management
on 03-05-2009 3:55 PM

Do you feel my heart beating? Do you understand? Can you feel the same? Am i only dreaming or is this posting an eternal flame?

Close your eyes, give me your comments darling.

DotNetShoutout wrote Improving Software Process - A Letter to Upper Management - Tim Barcz
on 03-05-2009 5:28 PM

Thank you for submitting this cool story - Trackback from DotNetShoutout

Andrea J. Kendall wrote re: Improving Software Process - A Letter to Upper Management
on 03-06-2009 2:27 AM

This is my answer to the person who rightly talked about ROI.  The answer is simple, after 30 years lots of studies have shown how it is far more costly to fix a bug early on in the development cycle that has gotten into production.

Also bug in any IT system can cost the company a lot of money.  We have all had the experience of working on something and running into some bug where we lost our work.   More serious bugs have resulted in stopped production - remember the problems with the Black Berry a few years ago.

The point is that since most companies rely on IT in one way or another it can make a big difference to the bottom line if the software works right.

Jak Charlton wrote re: Improving Software Process - A Letter to Upper Management
on 03-06-2009 6:14 AM

@Andrea

>>This is my answer to the person who rightly talked about ROI.  The answer is simple, after 30 years lots of studies have shown how it is far more costly to fix a bug early on in the development cycle that has gotten into production.<<

Then the trick is, quote those studies, assume your audience hasn't read all the same stuff you have, refer to authoritative sources and case studies, give examples to prove each of your points in a business scenario and context.

Felix wrote re: Improving Software Process - A Letter to Upper Management
on 03-09-2009 2:24 PM

well, Proving bug fixes through tests really moved me. I wish I could adopt that, since it has so many different means to improve code (testability wise and code-confidenciality wise).

Pair programming is great, but I think that the Upper BizAdmin persons need a lot more then "15% less code" - and the "less bugs, quicker development, happier developers, and preservation of knowlage and experiance, and the value of seeking improved quality in every practice" should be more emphesized, I think.

How to reach that "Collective Code Ownership", and why is it different then pair programming, just on a larger scale?

Brillient post. I'm thinking of creating a shirt with these values.

Felix

Tim Barcz wrote re: Improving Software Process - A Letter to Upper Management
on 03-09-2009 2:35 PM

@Felix

You create a shirt and I'll buy some!

Thanks for the feedback.

Tim

iNeedMyJob wrote re: Improving Software Process - A Letter to Upper Management
on 03-10-2009 8:28 AM

I am dealing with a project now where non-functional requirements are not as important to management as functional. As a result we have lots of functionality that cannot be well tested, packaged, deployed, or maintained.

The Right Thing wrote The Right Thing
on 03-11-2009 11:53 PM

Pingback from  The Right Thing

Software Quality Digest - 2009-03-13 | No bug left behind wrote Software Quality Digest - 2009-03-13 | No bug left behind
on 03-13-2009 2:20 PM

Pingback from  Software Quality Digest - 2009-03-13 | No bug left behind

Kris wrote re: Improving Software Process - A Letter to Upper Management
on 03-19-2009 2:52 PM

Hello,

Please add your site at http://www.sweebs.com. Sweebs.com is a place where other people can find you among the best sites on the internet!

Its just started and we are collecting the best found on the net! We will be delighted to have you in the sweebs listings.

Regards

Kris

Ruth wrote re: Improving Software Process - A Letter to Upper Management
on 04-02-2009 11:20 PM

I recently came across your blog and have been reading along. I thought I would leave my first comment. I don't know what to say except that I have enjoyed reading. Nice blog. I will keep visiting this blog very often.

Ruth

http://pianonotes.info

Tim Barcz wrote Zero Defects In Software, Setting a Higher Bar
on 08-26-2009 2:04 PM

Several months ago I published a letter to upper management about improving software processes . 

Tim Barcz wrote Confessions of a First Time Manager
on 12-12-2009 11:10 PM

Many months ago I wrote a letter to upper management about principles of software development and the

Mike Cole wrote re: Improving Software Process - A Letter to Upper Management
on 04-11-2010 11:47 PM

Instead of writing a letter myself, I copied and pasted this link. Good post!

Jared wrote re: Improving Software Process - A Letter to Upper Management
on 06-22-2010 4:32 PM

I like your post.  However, being a QA guy, I couldn't help but find the spelling and grammatical errors in your post.  I hope it didn't hurt your effort.

What ever became of your letter?

Seo Company wrote re: Improving Software Process - A Letter to Upper Management
on 11-24-2012 10:30 PM

PLPCIL Thanks-a-mundo for the blog post.Really looking forward to read more. Really Great.

social bookmark submission wrote re: Improving Software Process - A Letter to Upper Management
on 01-19-2013 3:31 AM

1xDuay Thanks so much for the blog.Much thanks again. Great.

pills for weight loss wrote re: Improving Software Process - A Letter to Upper Management
on 01-31-2013 9:13 AM

aaY7Vi Enjoyed every bit of your blog post. Will read on...

http://bestmedicineonline.info wrote re: Improving Software Process - A Letter to Upper Management
on 02-15-2013 6:44 PM

SJKZBy Very good blog article.Thanks Again. Great.

buy social bookmarks wrote re: Improving Software Process - A Letter to Upper Management
on 04-28-2013 4:22 AM

ZsYwPM Great, thanks for sharing this blog article. Really Great.

slr lenses wrote re: Improving Software Process - A Letter to Upper Management
on 05-14-2013 1:22 AM

CFwwUt Fantastic article. Much obliged.

seo service wrote re: Improving Software Process - A Letter to Upper Management
on 05-29-2013 6:16 AM

BjaRY8 Major thankies for the article post.Really thank you! Fantastic.

social bookmarking service wrote re: Improving Software Process - A Letter to Upper Management
on 06-06-2013 7:02 PM

LhplRd Very good blog.Thanks Again. Much obliged.

cheap social bookmarks wrote re: Improving Software Process - A Letter to Upper Management
on 06-19-2013 7:26 AM

OWSNYu Thanks for the blog. Keep writing.

news and many more wrote re: Improving Software Process - A Letter to Upper Management
on 07-04-2013 9:49 AM

i6YWBT Muchos Gracias for your post.Really thank you! Really Cool.

buy viagra online cheap wrote re: Improving Software Process - A Letter to Upper Management
on 07-24-2013 3:48 AM

I really enjoy the blog post.Thanks Again. Keep writing.

buy cialis online cheap wrote re: Improving Software Process - A Letter to Upper Management
on 07-25-2013 5:44 AM

I appreciate you sharing this blog post. Really Cool.

buy viagra online cheap wrote re: Improving Software Process - A Letter to Upper Management
on 07-25-2013 10:53 PM

Wow, great article post.Thanks Again. Fantastic.

hot news wrote re: Improving Software Process - A Letter to Upper Management
on 07-26-2013 7:30 AM

D58aDu I appreciate you sharing this post. Will read on...

best news wrote re: Improving Software Process - A Letter to Upper Management
on 08-02-2013 12:00 PM

cUmk0U I truly appreciate this blog post.Much thanks again.

great link buildng wrote re: Improving Software Process - A Letter to Upper Management
on 08-19-2013 10:47 AM

pHsutG Great, thanks for sharing this blog article.Really looking forward to read more. Awesome.

awesome links for you wrote re: Improving Software Process - A Letter to Upper Management
on 08-20-2013 1:01 AM

uVD4Io Muchos Gracias for your blog post.Much thanks again. Will read on...

great seo service wrote re: Improving Software Process - A Letter to Upper Management
on 09-03-2013 11:16 PM

cw4Gbi I cannot thank you enough for the blog.Really thank you! Much obliged.

online business wrote re: Improving Software Process - A Letter to Upper Management
on 09-11-2013 6:27 PM

q7tKWs This is one awesome article post.Really looking forward to read more. Awesome.

pro link building wrote re: Improving Software Process - A Letter to Upper Management
on 09-24-2013 9:56 PM

ZXSRlU Thanks for the post.Really looking forward to read more. Much obliged.

best linkbuilding wrote re: Improving Software Process - A Letter to Upper Management
on 09-30-2013 7:23 PM

UnQGBq This is one awesome blog article. Keep writing.

best link build wrote re: Improving Software Process - A Letter to Upper Management
on 10-15-2013 7:38 AM

7SctMh Hey, thanks for the article post.Thanks Again. Much obliged.

top seo guys wrote re: Improving Software Process - A Letter to Upper Management
on 10-26-2013 12:47 PM

IebSHs A big thank you for your blog.Much thanks again. Great.

top seo guys wrote re: Improving Software Process - A Letter to Upper Management
on 10-31-2013 4:13 AM

8ThHbw Thank you ever so for you article post.Much thanks again. Much obliged.

great things to know wrote re: Improving Software Process - A Letter to Upper Management
on 11-17-2013 10:00 PM

Zi7NlI Wow, great post.Really looking forward to read more.

seo service wrote re: Improving Software Process - A Letter to Upper Management
on 12-15-2013 12:52 AM

zWapeA Thanks a lot for the article.Much thanks again. Want more.

check it out wrote re: Improving Software Process - A Letter to Upper Management
on 01-07-2014 7:22 PM

ZtI6vs Very good article. Really Cool.

nice site here wrote re: Improving Software Process - A Letter to Upper Management
on 01-15-2014 7:13 PM

VLdl2C Hey, thanks for the blog article. Want more.

nice seo guys wrote re: Improving Software Process - A Letter to Upper Management
on 03-22-2014 12:16 PM

1GphBF Enjoyed every bit of your article post.Thanks Again. Keep writing.

check this out now wrote re: Improving Software Process - A Letter to Upper Management
on 03-25-2014 7:16 PM

UiQimZ Thanks so much for the blog post.Much thanks again. Really Great.

check this out now wrote re: Improving Software Process - A Letter to Upper Management
on 04-05-2014 3:47 PM

6yl2LP Very good blog.Really looking forward to read more.

Add a Comment

(required)  
(optional)
(required)  
Remember Me?

About The CodeBetter.Com Blog Network
CodeBetter.Com FAQ

Our Mission

Advertisers should contact Brendan

Subscribe
Google Reader or Homepage

del.icio.us CodeBetter.com Latest Items
Add to My Yahoo!
Subscribe with Bloglines
Subscribe in NewsGator Online
Subscribe with myFeedster
Add to My AOL
Furl CodeBetter.com Latest Items
Subscribe in Rojo

Member Projects
DimeCasts.Net - Derik Whittaker

Friends of Devlicio.us
Red-Gate Tools For SQL and .NET

NDepend

SlickEdit
 
SmartInspect .NET Logging
NGEDIT: ViEmu and Codekana
LiteAccounting.Com
DevExpress
Fixx
NHibernate Profiler
Unfuddle
Balsamiq Mockups
Scrumy
JetBrains - ReSharper
Umbraco
NServiceBus
RavenDb
Web Sequence Diagrams
Ducksboard<-- NEW Friend!

 



Site Copyright © 2007 CodeBetter.Com
Content Copyright Individual Bloggers

 

Community Server (Commercial Edition)