Reflecting on 2009

December 31, 2009

It’s the end of the year, and it’s time to look back at this blog, and to start thinking about where I will take this blog in 2010.
I started this blog on in January of 2009 for multiple reasons:
To re-examine my own thoughts and experiences gained over the years. The act of explaining my thinking to others via this blog forces me to consider why I have certain points of view, and possibly alter them based on additional thought and consideration on my part.
To challenge myself to read, discuss, and think about programming and managing software development. The objective being to add to my current knowledge and understanding based on the extra effort required by writing about software development.
To exercise and develop my writing skills; after all, the act of writing forces you to think about what you are writing, how you will approach a given topic, and it really forces you to clarify your thoughts. All worthwhile as far as I’m concerned! In fact, I’m finding that I am able to write with clarity at an increasingly faster rate now than I did a year ago.
To utilize Google Blogger and see what I could do with Google’s tools.

The BIG concern that I had when I started this blog was whether or not I could sustain my pace. I determined the title and objective of the blog, and I settled on a goal of posting once per week. Before officially launching the blog, I had brainstormed a list of 20 topics and pre-wrote about 4 or 5 posts in advance. I then got to work setting up my blog.

So far, meeting my once-per-week quota hasn’t been an issue for me. I find that I write in spurts, and that I can produce several blog posts in fairly short periods of time, typically on a slow weekend. During the week, I am mindful of things that I read or any dialog that comes up that might suggest a topic. I write these down and mentally play with them in the back of my mind. When I have a hour or two of time available, I start writing.

I would like to thank all of you who are reading this blog. I have picked a few public followers, and I know that there are many more quietly reading my posts at their leisure. My questions to you are:

What would YOU like to see in this blog?

Do you enjoy my writing style?

Are my topics worth reading about?

My tendency is to write longer posts than some blogging wisdom states is wise. Other advisors advocate that I should post more than once per week. And of course, for every piece of advice there are counter-points. Some bloggers say that posting on a consistent schedule is what really matters, and once a week is fine. Length is not an issue with some bloggers, either. They advise that I write posts that are of sufficient length to cover the topic at hand, and not to short-change a topic to meet an artificial limit on length.

The frequency and length of my blog posts are based on my own experience. I can’t read everything that is out there, but if I find blogs that I enjoy – ones that are informative and offer a good perspective – I certainly don’t fault someone for writing 900 words instead of 300. I don't like having to read multiple posts spread over a few days or a week to understand the author's full message. I would prefer to read it in one shot.

I consider 2009 my practice year. In 2010, my goal is to increase my readership, and that means providing content that has appeal to YOU, in ways that you want to see that content. So, dear reader, what is your opinion? What I am doing right, and what would you like to see changed?

My Reading List

December 23, 2009

It’s the holiday season, and I’m sure that you’ve had your holiday lists to deal with, whether it be a list of gifts for your children, a “honey do” list (like stringing the Christmas lights on the house), a shopping list, etc. Lists of things haven proven to be popular blog posts for other authors, like “The Top 100 Development Blogs” or “The Top 50 Software Development Book,” so I decided to produce one of my own.

My objective was to do a quick inventory of books in my own library that I’ve accumulated over the years and produce an un-ranked list of business and software development books, focusing my attention on books that I would recommend to anyone that is tasked with managing software development and/or trying to build a successful software business. I started out thinking that this would be a “Top 10” list, but I found myself unable – perhaps unwilling is more accurate – to prioritize THAT much!

My criteria:
  • The book must be a part of my personal library. The book represents something that I’ve purchased with my own hard-earned money.

  • The book relates to business or software development, and I feel that there is real value in reading the book. I look for books that provide solid information, excellent perspectives and insight, with a little inspiration tossed in for good measure.

  • Copies must still be available to purchase.

The List:

v Swim with the Sharks Without Being Eaten Alive: Outsell, Outmanage, Outmotivate, and Outnegotiate Your Competition by Harvey Mackay

v What They Don't Teach You At Harvard Business School: Notes From A Street-Smart Executive by Mark H. McCormack

v In Search of Excellence: Lessons from America's Best-Run Companies by Thomas Peters and Robert Waterman, Jr.

v The Dilbert Principle: A Cubicle's-Eye View of Bosses, Meetings, Management Fads & Other Workplace Afflictions by Scott Adams (Fun, and a great resource for things not to do!)

v The Innovator's Solution: Creating and Sustaining Successful Growth by Clayton M. Christensen and Michael E. Raynor

v Good to Great: Why Some Companies Make the Leap... and Others Don't by Jim Collins

v The Discipline of Market Leaders: Choose Your Customers, Narrow Your Focus, Dominate Your Market by Michael Treacy and Fred Wiersema

v First, Break All the Rules: What the World's Greatest Managers Do Differently by Marcus Buckingham and Curt Coffman

v Managing for Excellence, The Guide to Developing High Performance Contemporary Organizations by David Bradford and Allan Cohen

v Coaching for Improved Work Performance by Ferdinand Fournies

v A Passion for Excellence: The Leadership Difference by Tom Peters and Nancy Austin

v Crossing the Chasm by Geoffry Moore

v Execution: The Discipline of Getting Things Done by Larry Bossidy, Ram Charan, Charles Burck

v The Business of Software: What Every Manager, Programmer, and Entrepreneur Must Know to Thrive and Survive in Good Times and Bad by Micheal Cusumano

v Programming Pearls and More Programming Pearls: Confessions of a Code by Jon Bentley

v Rapid Development: Taming Wild Software Schedules by Steve McConnell

v Code Complete: A Practical Handbook of Software Construction by Steve McConnell

v Writing Solid Code: Microsoft's Techniques for Developing Bug-Free C Programs by Steve Maguire

v Microsoft Secrets: How the World's Most Powerful Software Company Creates Technology, Shapes Markets and Manages People by Michael Cusumano and Richard Selby

v The Art of What Works: How Success Really Happens by William Duggan

v Managing Humans: Biting and Humorous Tales of a Software Engineering Manager by Michael Lopp

v Software Requirements by Karl Wiegers

v Getting Results from Software Development Teams by Lawrence Peters

v The Practical Guide to Defect Prevention by Marc McDonald, Robert Musson, and Ross Smith

What I’m reading right now:

Coders at Work: Reflections on the Craft of Programming by Peter Seibel

Agile Principles, Patterns, and Practices in C# by Robert C. Martin and Micah Martin.

Have a Merry Christmas and a Happy New Year!

Never, Ever, Be Too Clever

December 18, 2009

When I was in college (and we aren’t exactly talking about yesterday) my computer instructor – who had years of practical experience under his belt – was adamant on one point: If we passed in code that smacked of job security programming, he would cut our grade in half. His message was clear, that our code needed to be logically and clearly expressed because some day other people would need to update it, and in order to do so they would need to understand what they were looking at.

It was obvious that my instructor had been frustrated by code that was unnecessarily complex during his career. Furthermore, he attributed much of this complexity as both unnecessary and deliberate on the part of the developers who wrote the code, with the conclusion that the developers were making themselves “indispensable” by deliberately convoluting the code.

I’ve seen my share of difficult-to-understand code over the years. In my opinion, some people have the specific intent of playing the job security game. In other cases, people are almost too smart for their own good. They have a lot going on inside of their heads, and while they do a great job of keeping a mountain of variables and conditions circulating around their brains, the resultant expression of logic is almost diabolical. Yes, the code works, but it takes a great deal of time and an extraordinary intellect to unravel the intricacies of their logic.

In other cases there is an inexperienced or less than capable programmer involved. And this programmer hasn’t thought the problem through before coding and ends up throwing code at the problem until he or she can get it to work, making one heck of a mess in the process.

As a manager, if I find that we’ve missed a code review that should have prevented problems like this from making it into the production code, I’m upset! Maintainable, understandable code is a BIG deal. Allowing poor (difficult to maintain) code to find its way into the code base will drain your productivity later. I want code reviews to serve as a gate to prevent problems from making their way into the code. As part two, I’ll work with the individuals to improve or change their game, reducing the instances of poor code from being produced in the first place.

I’ve seen other problems with code, problems that have their roots in inappropriate design. One example from my own recent experience occurred when I dove into a complex issue with one of our Windows®-based applications.

The real problem with this code is the fact that messaging is being used and abused. Windows® messages are being peeked, pre-processed, forwarded, and raised – you name it and this code is doing it. Finally, the timing of when the messages are processed is also very important. All of this is being performed in the name of collecting, formatting, validating, and coordinating the (redundant) display of data.

We ran into problems when we needed to extend functionality in a very small way to meet a customer need. As we extended the functionally, we broke things in the process. I ended up working on this issue myself, but every time I fixed one problem, another cropped up someplace else. I refer to this situation as the whack-a-mole problem. As it turns out, two us of independently wrestled with the problem in similar ways and ended up with the same conclusion: Based on the current design, there was little chance that we could get everything running in accordance with the existing design.

I know what you are thinking: re-factor time, right?

Well, we are talking about C++, MFC legacy code here. And this problem is greater than a refactoring effort alone. Refactoring is one thing, completely re-designing and re-implementing is another. In fact, we are in the process of re-architecting and re-writing the business capability that this code supports in .NET, gradually moving key processing to Web Services and browser-based technology. None of this code will be carried forward, and certainly NOT in the way it is designed now.

So I settled for a well-contained, well-commented, two-line hack to get everything running and to make us whole as far as our customers are concerned. It is annoying that this circumstance exists within our code base, but I really can’t justify investing any more time or energy in modifying our legacy code because it will divert resources from our more strategic, stay-in-business efforts.

I cannot state for sure why this code is designed the way it is, since I’m not the one who designed it and I was not a part of the equation when this code was implemented. A design review should have been conducted to prevent this design from ever being implemented. This code resembles instances where I’ve seen technologies and certain approaches used because someone read about something and wanted to try it, which is not a great reason for implementing that something in production code!

This can be tricky territory, but there is a line between staying current and applying what you’ve learned and going out of your way to use technologies or approaches because you want to stuff your resume. As a professional, it is NOT okay to use the company that you work for as your personal software lab.

If you want to explore something, talk to your manager. Work on a side project that is geared at providing your organization with information and a working example of the technology. Or get assigned to a project where utilizing the technology makes sense.

But don’t compromise the maintainability of the code base – a corporate asset – by using designs and implementing things just because you want to learn about them. Be responsible. The use needs to fit the need.

By all means keep learning about technology and the industry. It’s great to know that something exists that might help your specific situation. And if it is an appropriate fit, learn about it and discover the correct way to implement it for the benefit of your project and the code base.

Software should be an organized, clear expression of logic that clearly meets the needs that the software is attempting to address right now. Maintainable software is about using a reasonable structure, one that meets the business need, yet doesn’t try to reach too far into the future. If there is a need for the software design to evolve to meet more complex needs later, evolve it when later arrives, not now.

Designing too far into the future is attempting to anticipate problems that you might not encounter, because the problems themselves might change. After all, requirements are always a moving target, are they not?

Book Review: Talent is Never Enough

December 11, 2009

I find the art of achieving success to be intriguing. Many people attribute success to luck, to being in the right place at the right time. Others argue that you make your own breaks, and being in the right place at the right time without being prepared does you no good at all. What does it take to be prepared? That was the question that leapt into my head when I came across a book titled Talent is Never Enough: Discover the Choices That Will Take You Beyond Your Talent by John C. Maxwell (Copyright ©2007).

I flipped through the book, and it appeared to have a lot of information in it, so I purchased it for my summer reading, even though I had a few other books already selected. However, I read fast, and I need several books to get me through the summer…

The book began by articulating something that I am in full agreement with, and that is to stop working on your weaknesses, and start working on your strengths. As a manager, I’ve always followed this advice that I got from reading another book several years ago: First, Break all the Rules: What the World’s Greatest Managers Do Differently by Marcus Buckingham and Curt Coffman (Copyright © 1999 by The Gallop Organization). Since reading that book, I have always sought to understand the strengths and preferences of those who work for me, so that I could best align the work with the abilities and preferences of my staff, but I digress.

Maxwell raised an interesting point in the introduction to Talent is Never Enough, and that is the observation that people can increase their ability in an area by only 2 points on a scale from 1 to 10. This is an important point because if you happen to be a 4 in a given area, you have the potential of reaching a 6, a little above average. If you are a 7 – where your strength lies – you have the potential of becoming a 9, effectively moving yourself from a 1 in 10,000 talent to a 1 in 100,000 talent.

Find your talent – your strength – and develop that talent to its fullest extent.

However, the main thrust of the book was the talent needs to be accompanied by other things, and that you won’t make it on talent alone. You need to be a “talent-plus” person. Many of the “plus” items were not new to me, but it was the first time that I have seen these articulated in one place, and expanded upon in fantastic detail. What are those “plus” things?

Belief. Believing in yourself, your potential, your mission comes from within, and will remove artificial limits that you may be placing on yourself.

Passion. It energizes and empowers you. It enables people to make the most of whatever talent that they possess.

Focus. It directs your talent. Avoid taking on everything; Attempting everything is like attempting nothing. It will suck the life out of you.

Preparation. It positions your talent. When you don’t prepare, things that you hoped won’t happen do happen.

Practice. It sharpens your talent. You play at the level you practice.

Perseverance. It sustains your talent. It means succeeding because you are determined to, not destined to.

Courage. It what you draw upon when your talent is tested. If you fail to step up and meet a challenge, you will not realize the depth of your talent.

Teachability. It expands your talent because you are willing to discover and grow. It is an desire to listen, learn, and apply.

Character. It protects your talent. Many people with talent make it into the limelight, but the ones who have neglected to develop strong character rarely stay there long.

Relationships. They influence your talent. Some relationships take from us, like critics, gossips, backstabbers, control freaks. Other relationships add to us, like family, creative people, fun people, encouraging people, successful people.

Responsibility. It strengthens your talent. People who handle their responsibilities well get the opportunity to handle additional responsibilities.

Teamwork. It multiplies your talent. Talent may win games, but it is teamwork that wins championships.

Overall, I found Talent is Never Enough to be a very good read, and I recommend it to anyone who wants more insight into why you need more than just talent alone.

The True Definition of Success for Software Projects

December 4, 2009

The Challenge in Defining True Success
Let’s examine the question of the classic definition of on time, on budget, of high quality, with the expected features as a traditional measure of success. Is it possible for a project to meet this traditional measure of success and still be regarded as a failure? I’ll answer that question with a question: What if the project ultimately fails to provide the anticipated business value?

Conversely, what if a project fails on the traditional criteria, yet delivers greater business value than anticipated? It happens; in fact, CIO Magazine reported on this very phenomenon in an article called Applied Insight - Tracks in the Snow, by R. Ryan Nelson.

In the article, Nelson cites an example of a financial services company that developed a new system to improve collections performance that was six months late and cost twice the original estimate – failing in the classic sense. However, once in production, the system provided a 50% increase in the number of concurrent collection strategy tests in production. On that basis, the project was judged to be a great success!

Relate this back to the results from Scott Ambler’s 2008 survey that I discussed in my previous post, The Elusive Definition of Success with Software Projects, where 70% of the respondents believed that providing the best ROI is more important than delivering under budget. This scenario supports the opinion of the respondents perfectly.

There are other realities in the business world, and one is that business priorities shift over time. Can you state with certainty, conviction, and honesty that today’s priorities will remain firm during the entire course of a year? Unfortunately, there are a number of software projects that have this implicit expectation because they have delivery dates set one year or greater into the future!

Achieving Software Project Success
The situation above, where a project was six months late and cost over twice the original estimate – yet was still regarded as successful – points to the first important point in achieving success: Understand your expected return.

Understanding the benefit that you expect to get out of the software provides you with a valuable insight about both the worth of the software as well as defining exit criteria. One thing is certain, and that is that software projects are not as predictable as everyone would like them to be (I won’t go into the reasons here). If project timelines continually move into the future, you need to start asking yourself if the additional investment is worth the payoff.

The 2006 Chaos Report from The Standish Group found there was an 18.8% improvement over a 12-year period for software projects in meeting the on time, on budget, and expected features criteria. This places only 35% of all software projects as succeeding according to this classic measure, but it is still worth examining what drove this improvement to understand what it takes for projects to be successful.

When asked for the reason that project success rates improved, Standish Chairman Jim Johnson replied, “The primary reason is the projects have gotten a lot smaller.” And this means both smaller teams and a smaller number of features.

Smaller teams are more productive than larger teams. This model is supported by studies by Quantitative Software Management (QSM), a company that maintains a comprehensive database of software development project metrics, with its data coming from its own projects and a repository that is part of its SLIM estimation product.

Here’s a pop quiz for you, based on QSM data: There are two software teams that must deliver a project with a size that is estimated to be about 40,000 lines of code. One team, Team Large, has 29 resources compared to Team Small, with 3 resources. How much faster do you think Team Large will be?

According to the QSM data, the difference would be a mere 12 calendar days! The other significant difference would be the fact that Team Large would consume 151 more person-months more Team Small. This begs the question: Why did Team Large experience such poor productivity?

There are a number of reasons why large teams suffer productivity drops. Teams start out as a collection of individuals, and they must spend some time getting to know each other’s strengths, weaknesses, preferences, and idiosyncrasies. Some mixes of people work better than others, and no matter what it takes time for people to work effectively as a team, and this will take much longer with a larger team.

Small teams can also coordinate their work far more easily and quicker than larger teams. Larger teams have greater overhead, including more lines of communication. And when there are more people involved with more lines of communication, the greater the opportunity for miscommunication to occur.

The result of coordination and communication issues can be just what another aspect of the QSM data reveals: that the larger teams produce over 6 times as many defects as smaller ones. As you can imagine, this introduces a significant burden on productivity, since defects must be logged, reviewed, fixed, tested. Overall throughput – getting things squarely into the “done” column – is significantly impacted.

A smaller number of features are easier to contend with. A large feature count is more difficult for project teams to wrap their heads around. My own personal experience is that all too often, projects with large feature counts devote less time to each feature than smaller projects.

If less time per feature is spent to the point where the time is inadequate to thoroughly define each and every feature, ambiguities creep in, and they will remain quite undetected until later in the software development process. But they will surface and cause problems – moving a seemingly well-defined project into the challenged category, particularly if those ambiguities create expensive re-work.

The other problem with a large feature count is that a greater amount of planning, design and testing is required to ensure that all of the features work in harmony. The greater the feature count, the greater the challenge of maintaining internal consistency; features cannot conflict with one another or otherwise interfere with related processing. Quite simply, a large feature count increases the likelihood of defects occurring.

Focusing on a small set of features is also important because business priorities shift over time. Projects with long time frames are likely to have features that are deemed as important now, but won’t be as important when the software is delivered. And let’s not forget that there is uncertainty about the anticipated benefits in the first place; the realized benefit could be less or greater than what was anticipated at the outset. A smaller feature set will have a faster delivery schedule and enable the business to assess the reality of the benefit(s) much earlier.

There is also the problem where stakeholders of a software project have a high-level goal that they want to achieve, but that goal gets lost when the definition of the features is delegated to others in the organization. While it is certainly appropriate to involve those who work in the trenches, as they will be the ultimate users of the software, there is a tendency to add a variety of “must have” features to the list during the process, some of which will not necessarily be related to the high-level goals of the project. A stakeholder review of the features can catch this situation before expensive software design and development begins.

Notice that I did not advocate using any one software development process over another, but instead sought to focus on the key ingredients to achieve higher productivity and greater success:
  • Understand your expected return and weigh this against the investment that you are making over time.
  • Focus attention on the smallest set of features that deliver the greatest business value.
  • Use the smallest team possible to achieve maximum productivity.
I personally believe that these are core principles that can help any software project be regarded as a true success, along with being a positive experience for all those involved! These principes can be summarized as striving to meet the following, generic goal:

Software needs to provide the greatest possible business value through the implementation of the least number of features possible, using the smallest size team possible, and be delivered in the shortest time frame that ensures quality.

Scott Ambler’s December 2008 Software Development Project Success Survey

Standish Group Report: There’s Less Development Chaos Today by David Rubinstien, March 1, 2007

Standish Group: Project Success Rates Improved Over 10 Years

CIO Magazine - Applied Insight - Tracks in the Snow By R. Ryan Nelson

ComputerWorld - Development Study: Haste Makes Waste By Linda Hayes, September 23, 2005