January 31, 2009
More often than not, during tight economic times – like what we are experiencing today – many companies not only cut costs (and typically this means people), but they also focus their attention in two seemingly contradictory ways:
1. “Doing more with less.”
2. Asking for more innovation and creativity from their employees.
Can software projects meet these two demands? You can – if you understand your true programming capacity in relation to your planning.
My experience is that most software projects are trying to do too much with the staff that they have. Instead of “doing more with less,” I feel that your motto should be: “Decrease time spent on low-value work and increase time spent on high-value work.” Yes, it’s a bit of a qualifier, but I advocate concentrating your efforts on performing more high-value work with the reduced staff that you have in order to improve results.
Ask yourself the following questions: How good is your organization about meeting project schedules? Are you hitting your dates with quality code? Are your programmers contributing in innovative and creative ways? Do your users feel that they are receiving value from the software that you deliver? If you are achieving all of these things, congratulations!
One common complaint that is often voiced with software projects is that developers are optimistic when it comes to estimating, but they aren’t the only ones guilty of this. I’ve seen entire organizations believe in schedules that they really shouldn’t. This ultimately leads into heads-down, aggressive programming and testing, with no time left over for anything but the essentials. Innovation and creativity take a back seat to the schedule.
The main problem is that many people believe that they have more programming capacity than they really do. Consider how project schedules are typically created. Many times, programming estimates are provided in days or hours. Do you schedule – and subsequently plan and bank on – eight productive hours per day, per programmer? I hope not! At my company, we recognized that interruptions and general “administrivia” will get in the way. At one point we attempted to use six-hour days as our “ideal developer day” for planning purposes, but this didn’t work out.
One simple reality is that there are hours in a day, and then there are productive hours. This isn’t just a programmer problem. It surfaces in any white-collar work. While your actual experience may vary, mine has demonstrated that four genuinely productive programming hours per day is the norm. Why? Because there is more to programming than coding; things like thinking and designing come into play. I’m interested to hear what your thoughts are.
Another problem stems from the abuse of the word “estimate.” Unless the same person is writing same application that they wrote last week, estimates should be viewed as an approximation, a ballpark. There is a uniqueness to every development project that makes defining exactly how long it will take to deliver a feature (or set of features) difficult to determine with great precision.
While this can be mitigated by ensuring that the requirements are very precise and that sufficient time to design the feature(s) has been provided, the tendency is to short-change this process and hold programmers accountable for meeting their “commitments.” This situation is in part why Agile development has taken root.
Also consider the following: If you want programmers to contribute in creative and innovative ways, they need time to keep up with technology, to understand the task at hand, and to think about and collaborate with others in applying technology. If people are pulling out all of the stops to meet aggressive deadlines, there won’t be any think time available.
I have another data point related to the scarcity of available programming – specifically the amount of programming that you should expect – that I find extremely interesting: Lines of code per day. No, I am not attempting to measure productivity! This is all about pointing out the scarceness of programming resources.
An industry example is Microsoft Vista. From what I have read, Vista comprises approximately 50 million lines of code. Reports seem to vary on this, but the typical programmer on Vista is said to have produced an average of about 8-20 lines of code per day, with a maximum reaching 50 lines of code per day. Using 230 working days per year as an average, we’re talking about 4,600 lines of code per year, per typical programmer (if you use the figure of 20 lines of code per day). I’ve seen other estimates that put the average lines of code per programmer on Vista nearer to 5 lines of code per day, or about 1,150 lines of code per year, per programmer.
If these numbers sound low to you, take a hard look at the realities in your company. And remember that there is more to programming than just producing code; For example, the problem domain needs to be understood and design work has to take place. Poorly-designed code that does not meet the business need will result in waste and more defects that must be fixed before the software is deemed usable. (Consider the knocks Vista has taken in the marketplace.)
To summarize, programming is a complex, detailed undertaking that requires a lot of planning, designing, and old-fashioned thinking. Programmers need to be working on those projects that provide the highest possible value, period. And don’t waste their time, there is so little available to waste!
January 24, 2009
Software development is a classic “knowledge worker” endeavor, and those knowledge workers involved with delivering projects need information as input, otherwise you run the risk of a team making day-to-day decisions that will work against your intended purpose. In today’s tough economic conditions coupled with global competition, focusing on delivering the greatest value for the dollar invested is of paramount importance.
A big problem area in software is prioritization. What features will provide the maximum benefit? You want to ensure that software teams are working from a prioritized feature list. Without one, teams can spend significant time and effort delivering low-priority features.
A software team lacking an understanding of priorities (and the desired benefit) will organize their work in other ways, such as grouping the development and testing of similar features together. If someone happens to be working in one section of code, it will be considered both logical and optimal to build out two features instead of one, even though one of those features doesn’t contribute significantly to the benefit side of the equation.
I’ve personally been frustrated in the past by product managers – working as part of the management team – who didn’t effectively prioritize. I can recall asking what the business priorities were when I was presented with a list of potential features for the next release of a product, only to be told, “Tell me how long it will take to build each feature, and I’ll tell you whether we’ll include it in the release.”
You heard correctly, our “prioritization” was all about how whether something fit into the timing of a release! This lack of prioritization meant that I was tasked with figuring out how much of that list I could complete; I was judged on quantity.
Instead of focusing on those features that provided the maximum benefit, my staff spent time estimating a wide range of features, some of which we knew wouldn’t be worked on once the estimating was done. In addition, I spent my time optimizing the feature count targeted for a release, mixing and matching potential features in such a way that my staff was optimally aligned based on their skill set and availability (with their availability based on my ordering of the feature delivery).
Was this the most effective use of our time? Did we end up spending valuable time implementing features that were of marginal benefit to our company? You bet. This situation is not only a time-waster, it is de-motivating. High-performing teams and individuals want to make valuable contributions; they want to be engaged in meaningful work.
The management team, who typically is the one championing the desire for high-performing, engaged employees (I am hearing this more and more these days) needs to set the tone by attaching meaning to the work – and that means ensuring that the work being performed has true value to the company. There are two sides to the motivation coin, and management owns this side.
Related to this, I’ve had people tell me that they don’t engage in a cost/benefit analysis (these happen to be companies with in-house staff, not software companies that need to profit directly from their efforts). Companies that fail to perform a cost/benefit analysis are failing in prioritization; they are likely keeping their staffs very busy, but are they being as effective as they could be? Bottom line: it pays to perform a cost/benefit analysis to ensure that the intended benefit is worth the investment.
After all, in tough economic times like this, companies everywhere are looking to be more productive, right? Before sponsoring a project you should understand the business goals of that project, the benefits you expect to derive, what investment in time and money is acceptable, and communicate that information to the software team. At least you should if you want to everyone involved to understand the results that you hope to achieve and expect people to be motivated in achieving those results.
Teams that understand the business objectives, key benefits and constraints can help shape the success of the project. Let’s face it, software projects are expensive, and if results are what you want, share this information! Knowledge workers armed with information and motivated towards achieving meaningful goals can contribute towards the outcome in one of two possible ways:
- The team can offer up ideas that shape the ultimate solution being delivered, generating ideas to leverage technology in new ways. Don’t – and this is a big DON’T – be married to your initial concept of a solution! Be open to suggestions early on in the process. It can pay big dividends in terms of the overall success of a project, and may even allow you to exceed expectations instead of just meeting them.
- The team can determine that the project as defined cannot be delivered within the time and/or budget constraints that would deem it a success. Be prepared to listen here, and be prepared to make adjustments. Perhaps there are characteristics about the project that can be reduced or simplified in order to reach the business objectives. If something is going to cost more (in some cases, far more) than the anticipated benefit, wouldn’t you want to know this before getting so deep into the project that you felt that you just have to keep going, despite the cost?
January 17, 2009
However, if something is not available, then someone needs to write it, assuming the cost/benefit analysis says yes. And before taking on a development effort, I would be sure to understand whether the benefit derived from building that something is worth the expense.
Once a development project is under way, customer satisfaction – including the perception the customer has of the development team – is gauged on how quickly those features that provide the maximum benefit are delivered, with quality. And this can be significantly accelerated by leveraging industry expertise and existing code.
In my book, the less code that you have to actually write to solve that problem, the more productive you are. Any good development shop will look towards other companies that provide components that can be purchased, make use of vetted frameworks or open source libraries as well as leveraging knowledge and examples that exist on numerous web sites. The bottom line: if you can leverage previously developed and tested code into your solution (or at least approaches to the problem), the result will be greater speed and quality.
Note that I used the phrasing: "leverage previously developed and tested code." The act of design and writing software implies that there is some uniqueness in what is being developed. And that since you cannot purchase an exact solution off the shelf, the best that you can hope for is a little leverage. But even some leverage is better than none.
This desired uniqueness that is part of every development project is also why defining software output is difficult. Not only is the output different for every project, the inputs –also known as requirements – will be different as well.
Since both the inputs and the outputs are variable, you really need to examine the contributions made by individuals, teams, the organization direction as well as the clarity and depth of that direction, and the handoffs (communication and collaboration between these entities) in order to achieve maximum productivity.
The final measure – your results – will come from your customers. Are they dissatisfied, satisfied, delighted, or “raving fans?”
January 10, 2009
Over the years, countless attempts have been made to define and measure software productivity, which means that output must be defined. The “big three” measures that are invariably used:
- Lines of code
- Function Points
- Defect Counts
While striving to measure productivity is certainly admirable, there are definitely problems with using any of the above in isolation. Even worse, if just one of the single “productivity” metrics mentioned above ends up as a measure of a programmer’s job performance, then you have started down a very slippery slope. The problem is that if you have reduced the judgment of complex work to a single element. The result is that you will get what you ask for, but it won’t be what you wanted!
Let’s examine using lines of code as a metric. This sounds like a great measure – after all, a developer needs to write code to tell the computer to do something, right? Well, if lines of code are what you measure productivity on, you’ll get lines of code, in spades.
Here’s a quick example that jumps to mind from my own experience. In updating some date calculation routines, I came across a previously-written, 100-line routine that needed to be modified. Yes, the code worked, but it needed to be extended.
One thing struck me almost immediately when I started looking at this routine; whoever developed it did not make use of date routines available within the language that we were using! The result was that this routine was much longer and more complex than it needed to be. By leveraging date features available with the language, I was able to shrink this routine to less than 20 lines of code.
Was the programmer who wrote an unnecessarily long routine truly “productive?” Maybe this individual didn’t know about these features, but should have taken the time to learn them. The result would have been more maintainable code, even if it took a little longer for that person to actually write the routine. If you are counting lines of code without taking time to put in conditions that make this type of coding unacceptable – something that will introduce more overhead and organizational gymnastics – this is what you will get.
And what about my lines of code count in this scenario? Shouldn’t I receive some type of credit for shrinking lines of code, since reducing the complexity made this routine more understandable and maintainable?
Let’s assume that I received credit for any new code that I wrote, including full credit for the lines of code that resulted from my re-factoring someone else’s code. Did this mean that other individual was rated as productive as well, even though he/she wrote something that was begging to be re-worked later? (In this case, much later; the code in question was a few years old by the time I encountered it.)
The lines of code metric is the simplest to explain (and I won’t bother with the others), but it surfaces the one key tenet:
Using a single metric does not measure true productivity.
And if you insist on using a simple metric to gauge complex work, you will need add rules around what is acceptable and not acceptable to avoid incenting individuals into "gaming" you – working towards an end result that ultimately does not do you any favors. And that adds overhead to your organization without adding any real benefit.
Don't get me wrong, metrics can be good. However, if you manage complex work, then you need to examine a series of metrics in order to gauge how well you are performing.
January 4, 2009
In my development days I was always concerned with:
- Producing workding software as quickly as possible that met the needs of the users.
- Producing clear, concise, maintainable code that I – or someone else – could pick up and easily modify at a later date.
- What should each developer be paid?
- How do I assess and help to improve individual performance?
- How do we (there are a few of us involved) assess and help to improve team performance?
- How do we motivate and reward individuals and teams?
- What practices and processes should we adopt to make our development organization better?
Of course, I’m periodically asked fun questions by my boss. When he wants to understand productivity – or determine what I understand about it in relation to managing developers – he asks, “How do we know that we are doing better this year versus a year ago?” Or, as we discuss business direction, “What can we do to grow the business?”
When talking about improving productivity and delivering value to the customer, all of these questions are valid, as were the personal goals that I had as a developer.
Many times, I see “software productivity” defined strictly in terms of programmer productivity. In reality, the productivity of programmers is only one small aspect of the total productivity picture. I believe that true productivity is the product of:
- The knowledge, ability, and contributions of individuals.
- The collective effort of individuals collaborating effectively on teams.
- Processes and tools that support the work of individuals and teams.
- The organizational culture and the overall management of the company.
This provides a range of topics to explore, and I look forward to your perspectives as well.
January 3, 2009
This requires assessing and improving individual results, team results, and organizational results. Let’s face it; we are in an era of a global economy and global competition, and we need to do be doing the right things, and doing those things right.
The inspiration for an early theme that I will pursue came from a book “Contagious Success – Spreading High Performance Throughout Your Organization,” by Susan Lucia Annunzio. There was an interesting observation in the book: “Don’t confuse performance with productivity.”
This statement addressed a concern of managing knowledge workers in general, cautioning those of us in management positions not to over-emphasize productivity, lest we drive out the ability for (knowledge) workers to contribute to our organizations through innovation and creativity.
Personally, I feel that it is well worth exploring this area with as wide an audience as possible, so I’m hoping for both readership and feedback! Based on the research and comments I’ve seen in cyberspace, there certainly is a lot of confusion about software productivity, and very little on innovation.
My goal is to post weekly, and I most certainly look forward to the journey!
January 1, 2009
Like many other Web sites, softwareresults.blogspot.com makes use of log files. The information inside the log files includes internet protocol ( IP ) addresses, type of browser, Internet Service Provider ( ISP ), date/time stamp, referring/exit pages, and number of clicks to analyze trends, administer the site, track user’s movement around the site, and gather demographic information. IP addresses, and other such information are not linked to any information that is personally identifiable.
Cookies and Web Beacons
DoubleClick DART Cookie
- Google's use of the DART cookie enables it to serve ads to your users based on their visit to your sites and other sites on the Internet.
softwareresults.blogspot.com has no access to or control over these cookies that are used by third-party advertisers.
If you wish to disable cookies, you may do so through your individual browser options. More detailed information about cookie management with specific web browsers can be found at the browsers' respective websites.