Productivity for Software Estimators

1 Introduction

Software estimation, namely, software size, effort, cost and schedule (duration) are often causing animated discussions among the fraternity of software estimators. Normally, it is the senior Project Leaders and project Managers who carry out this activity.

Software development consists of a few disparate activities needing specialized knowledge, namely, in Requirements Gathering, analysis, and Management; Software Design, Coding, Independent Verification and Validation, Rollout / Deployment / Installation & Commissioning. Each of these activities is carried out by a differently skilled person using different tools, having different complexities.

2. Productivity

Productivity is defined as the rate of output for given inputs. Productivity is expressed as “so many units of output per day” or “so many units or output per hour”.

Productivity is also defined as the ratio of output to input.

For the context of this paper, Productivity is defined as the rate of producing some output using a set of inputs in a defined time unit.

3. Concerns with Software Size Estimation

The present scenario in the industry is that we have multiple measures, namely,

1. Function Points
2. Use Case Points
3. Object Points
4. Feature Points
5. Internet Points
6. Test Points
7. FPA mark II
8. Lines of Code
9. Etc.

There is no accepted way of converting software size from one measure to another.

One odd aspect of these measures is that the size is adjusted (increase or decrease) due to factors of complexity etc. A size is something that does not change. For example, a pound of cheese does not alter if the person weighing is less/more experienced, or the scale is either a mechanical scale or an electronic one – right?

Or the distance of one mile remains one mile if a young person is walking or an old man is walking or if it is a freeway or if it is a busy city street.

But the rate of achieving changes – an old man completes one mile slower than the younger one you go faster on a freeway than on a busy street.

There is no agreement on how to count Lies of Code – logical statements or physical statements, treatment of inline documentation.

These are some of the issues with size measurement.

4. Concerns with Productivity

The software development world is obsessed with giving one single, empirical, all-activities-encompassing figure for productivity.

Attempts have been made to give productivity figure as – such as 10 person hours per Function Point but with a rider that it could vary from 2 to 135 depending on the product size and other factors.

Some times ranges are given – such as 15 to 30 hours per Use Case Point.

Some times empirical formulae are worked out depending on a set of factors – such as in COCOMO.

Another aspect is that these productivity figures lump all activities – requirements analysis, design, review, testing etc – in one single measure. The skill requirements for these activities are different, the tools used are different, the inputs are different, outputs are different – lumping them all together under the head “Software Development” and giving one single figure of productivity at best can only give a very rough estimate but never an accurate one.

5. The Productivity Path

We have the following activities in software development –

1. Pre-project activities
a. Feasibility study
b. Financial budgeting
c. Approvals – financial and technical
d. Project go-ahead decision
2. Project startup activities
a. Identifying project manager
b. Allocating project team
c. Setting up development environment
d. Project Planning
e. Setting up various protocols
f. Service level agreements and progress reporting formalities
g. Project related training
3. Software engineering activities
a. User requirements analysis
b. Software requirements analysis
c. Software design
d. Coding and unit testing
e. Testing – integration, functional, negative, system and acceptance
f. Preparing the build and documentation
4. Rollout activities
a. Installing the hardware and system software
b. Setting up database
c. Installing the application software
d. Pilot runs
e. User training
f. Parallel runs
g. Rollover
5. Project cleanup activities
a. Documenting good practices and bad practices
b. Project post mortem
c. Archiving records
d. Releasing resources
e. Releasing the project manager
f. Initiate software maintenance

Now, when we talk of industry thumb rules of productivity, we are not clear as to how many of the above activities are included in the productivity figure.

Interestingly, no one would like to stake his life on the productivity figure – industry thumb rule – that is being floating around!!

Look at the nature of these activities –

1. Requirements analysis – here it is understanding what the user needs, wants and expects and documenting the same so that the software designers understand them and can design a system strictly in conformance with the stated requirements. There is a lot of dependence on external factors.
2. Software design – considering the alternatives of hardware, system software and development platforms, arrive at the optimal one, design an architecture that will meet the stated requirements and fulfill expectations and yet feasible with the current technologies and document the design in such a way that the programmers understand and deliver a product that conforms to the original specifications of the user. There are quite a few alternatives and this is a strategic activity and errors here have strategic consequences.
3. Coding – developing software code that conforms to the design and is as failure-free as possible – it is so easy to leave bugs inside!!
4. Code review – walking thru code written by another programmer and deciphering the functionality and try to guess the possible errors
5. Testing – trying to unearth all the defects that could be left in the software – it is an accepted fact that 100% testing is impossible!

Now with such variance in the nature of activities, it is obvious that the productivity of all these activities is not uniform. The pace of working differs for each of these activities.

These activities do not depend on the amount of software code produced but on other factors – such as –

1. Requirements depend on the efficiency and clarity of the source of requirements – users or documentation
2. Design depends on the complexity of processing, alternatives available and constraints within which the functionality is to be realized
3. Code review depends on the style of coding
4. Testing depends on how well the code is written – more errors are left, it takes more time to test and re-test
5. Coding itself depends on the quality of design

Therefore, we need to have separate productivity figures for each of these activities.

Drawing a parallel from the manufacturing industry, for punching hole in a sheet –
i. Machine setup
ii. Tool setup
iii. Load job
iv. Punch hole
v. Deburr hole
vi. Clean up
vii. Deliver the sheet for next operation

If multiple holes are punched, “per hole” time comes down, as setup activities are one-time activities.

If we look at “coding a unit” – the activities could be –
i. Receive instructions
ii. Study the design document
iii. Code the unit
iv. Test & debug the unit for functionality
v. Test & debug the unit for unintended usage
vi. Delete trash code from the unit
vii. Regression test the unit
viii. Release it for next step

Similarly, we can come up with micro activities for each software development phase.

5.1 Empirical or study-based Productivity figures?

Each of these activities has a different rate of achievement. We have to establish standard times for each of these activities. Then using the Work Study techniques like Synthesis or Analytical Estimation, we need to arrive at the over all time to complete the job.

Whether we use time study techniques to arrive at individual productivity studies or gather empirical data – to answer this query, we have to acknowledge that software development is not totally mechanical in nature nor is it totally creative in nature. Work Study acknowledges that it is not practical to time activities that have a creative component. Lots of work is being undertaken in the matter of “white-collar-productivity” and perhaps future may provide some methods to “time” software development productivity figures. As of present, empirical data seems to be the solution.

Where do we get data for this? One way is the Time Study using the Industrial Engineering techniques. Second and more easier, as well as reliable, is from historic data from the timesheets.

Most timesheet software available and is being used by the industry are oriented towards payroll and billing rather than capturing data at micro level so that it can be used for arriving at the productivity data. Most timesheets capture data at two, or three levels (project is always the first level, second and third can be module & component or component & activity or a similar combination) in addition to date and time. The timesheet needs to capture at five levels, namely, project, module, component, development phase, and the task accomplished – in addition to date and time for each employee. Thus data would be available to establish productivity data empirically in a realistic manner.

The present focus is on macro productivity – for all activities of software development. This needs to change and we need to shift our focus from macro to micro – productivity for all activities. The way to achieve is to modify our timesheet.

Benefits of productivity at micro level are –

i. Better predictability of software development
ii. Better quality estimates for pricing assistance during project acquisition/sanction stage
iii. More precise target setting while assigning work, which leads to better morale in the software developers
iv. More accurate cost estimation


6. Conclusion

The conclusions are that we need to shift focus from macro productivity to micro productivity; empirical data gathering is preferred for arriving at productivity figures and that improvement of timesheet is the way forward for computing micro level productivity figures.

10 early signs that someone will make a great leader

Many performance reviews have ended with a conversation regarding advancement opportunities for employees and what they need to do to get to the next level. Most of them think that to advance, they need to become a manager. So naturally I ask them the age-old question “What’s the difference between a manger and a leader?” It usually elicits an awkward pause in the conversation while they try to come up with something profound and insightful, but it ultimately ends up flat.

I tend to look forward to the rest of the conversation because I don’t believe that there is only one answer to the question. Each of us has our own answer, and it’s usually derived from our leadership story, which gets developed over time based on our backgrounds and experiences. Someone’s vision of what makes a leader is one of the keys to how they will act and grow over the years and will usually be an influencing factor in their success. Young leaders in every organization take their cues from those around them by the actions they observe. Realizing this is important for all organizations to ensure they are identifying and providing appropriate role models.

#1: Listening and communicating effectively

Have you ever worked with a person who always says yes but never delivers what you need? Many of us have felt the frustration of that scenario, so it’s exciting to work with somebody who takes the time to understand a problem while also asking the key questions to ensure that all expectations are met.

#2: Being energetic

Employees with energy tend to lift up the people around them. Leaders sometimes need to be able to boost a team when they are working on tough projects, and having this trait can make a big difference in the long run.

#3: Remaining calm under pressure

When big problems happen, teams look to their leaders for direction. When a leader isn’t available, who else do they turn to for guidance and decisions? Usually it’s the person who has kept his or her cool and has been trying to find a solution to the problem. Nobody wants to work with the guy who is yelling, “The sky is falling!” But they will be happy to work with somebody who can see the light at the end of the tunnel when nobody else can.

#4: Taking responsibility for their actions

We all make mistakes. Many of us know it way before our bosses find out. Leaders are always willing to admit to making a mistake when something doesn’t work out as they planned. Usually, they are also trying to learn from the problem to ensure it doesn’t happen again in the future.

#5: Acknowledging the contribution of others

How often do your team members celebrate each others’ successes? Since the business world can be pretty competitive, it’s difficult for us to see somebody else do well and not be concerned about how it affects us. Leaders learn early on that many of their achievements come on the heels of their team’s successes and the contributions of each individual. Understanding this and feeling comfortable with it early in their career is a powerful trait.

#6: Being comfortable outside their area of expertise

Developers may be good at solving problems with applications and hardware, but can they effectively gather user requirements? How about dealing with end users or managing a budget? As leaders mature, they realize that they are asked to be involved with projects and teams of all shapes and sizes. The ability to feel comfortable in a situation while not being the expert gets easier when they realize that they can always fall back on their leadership skills no matter what the topic. After all, they were asked to get involved because someone thought they would add value.

#7: Being willing to take risks

Do you have someone on your team who’s afraid of making a decision or taking any type of risk? Or maybe they aren’t afraid to make choices, but only when they’re confident that the risk factor is small. This will be a problem if they get into a leadership role. Taking calculated and educated risks are daily events in the world of management and leadership.

#8: Being able to convince others

Do you have somebody on your team whom people look up to? Or is there somebody the business likes to work with because that person makes them feel comfortable when discussing tech issues? Make sure you keep an eye out for those people. The ability to influence others and direct a project without actual authority is a great indicator that you have a solid leadership candidate on your team.

#9: Being comfortable reflecting on their strengths and weaknesses

Leaders always need to look forward and many times backward to try to avoid repeating the mistakes of the past. Most people like to get praise, but how do they deal with constructive criticism? Look for those who are comfortable taking time to reflect on their style and actions and how that influences those around them.

#10: Being able to adapt

Things are constantly changing in business today. Technical people who work best with a fixed roadmap will struggle in a role that has ever-changing priorities. Leaders need to the ability to adapt to their surroundings as well as to the needs of the company.

Remember that not everybody is ready (or willing) to be a leader. Plenty of techs are more than happy to stay involved in the nuts and bolts of a project or to just sit back and develop robust applications. But IT organizations need some type of leadership structure to help guide the department and to interface at different levels within the organization. While it’s not common to hear about senior technical managers being good organizational leaders, it does happen. The early identification of individuals who have some of the above-mentioned attributes allows current leadership to groom those people for the future — an important step in making a company effective and successful.

10 early signs that someone will make a great leader

Many performance reviews have ended with a conversation regarding advancement opportunities for employees and what they need to do to get to the next level. Most of them think that to advance, they need to become a manager. So naturally I ask them the age-old question “What’s the difference between a manger and a leader?” It usually elicits an awkward pause in the conversation while they try to come up with something profound and insightful, but it ultimately ends up flat.

I tend to look forward to the rest of the conversation because I don’t believe that there is only one answer to the question. Each of us has our own answer, and it’s usually derived from our leadership story, which gets developed over time based on our backgrounds and experiences. Someone’s vision of what makes a leader is one of the keys to how they will act and grow over the years and will usually be an influencing factor in their success. Young leaders in every organization take their cues from those around them by the actions they observe. Realizing this is important for all organizations to ensure they are identifying and providing appropriate role models.

#1: Listening and communicating effectively

Have you ever worked with a person who always says yes but never delivers what you need? Many of us have felt the frustration of that scenario, so it’s exciting to work with somebody who takes the time to understand a problem while also asking the key questions to ensure that all expectations are met.

#2: Being energetic

Employees with energy tend to lift up the people around them. Leaders sometimes need to be able to boost a team when they are working on tough projects, and having this trait can make a big difference in the long run.

#3: Remaining calm under pressure

When big problems happen, teams look to their leaders for direction. When a leader isn’t available, who else do they turn to for guidance and decisions? Usually it’s the person who has kept his or her cool and has been trying to find a solution to the problem. Nobody wants to work with the guy who is yelling, “The sky is falling!” But they will be happy to work with somebody who can see the light at the end of the tunnel when nobody else can.

#4: Taking responsibility for their actions

We all make mistakes. Many of us know it way before our bosses find out. Leaders are always willing to admit to making a mistake when something doesn’t work out as they planned. Usually, they are also trying to learn from the problem to ensure it doesn’t happen again in the future.

#5: Acknowledging the contribution of others

How often do your team members celebrate each others’ successes? Since the business world can be pretty competitive, it’s difficult for us to see somebody else do well and not be concerned about how it affects us. Leaders learn early on that many of their achievements come on the heels of their team’s successes and the contributions of each individual. Understanding this and feeling comfortable with it early in their career is a powerful trait.

#6: Being comfortable outside their area of expertise

Developers may be good at solving problems with applications and hardware, but can they effectively gather user requirements? How about dealing with end users or managing a budget? As leaders mature, they realize that they are asked to be involved with projects and teams of all shapes and sizes. The ability to feel comfortable in a situation while not being the expert gets easier when they realize that they can always fall back on their leadership skills no matter what the topic. After all, they were asked to get involved because someone thought they would add value.

#7: Being willing to take risks

Do you have someone on your team who’s afraid of making a decision or taking any type of risk? Or maybe they aren’t afraid to make choices, but only when they’re confident that the risk factor is small. This will be a problem if they get into a leadership role. Taking calculated and educated risks are daily events in the world of management and leadership.

#8: Being able to convince others

Do you have somebody on your team whom people look up to? Or is there somebody the business likes to work with because that person makes them feel comfortable when discussing tech issues? Make sure you keep an eye out for those people. The ability to influence others and direct a project without actual authority is a great indicator that you have a solid leadership candidate on your team.

#9: Being comfortable reflecting on their strengths and weaknesses

Leaders always need to look forward and many times backward to try to avoid repeating the mistakes of the past. Most people like to get praise, but how do they deal with constructive criticism? Look for those who are comfortable taking time to reflect on their style and actions and how that influences those around them.

#10: Being able to adapt

Things are constantly changing in business today. Technical people who work best with a fixed roadmap will struggle in a role that has ever-changing priorities. Leaders need to the ability to adapt to their surroundings as well as to the needs of the company.

Remember that not everybody is ready (or willing) to be a leader. Plenty of techs are more than happy to stay involved in the nuts and bolts of a project or to just sit back and develop robust applications. But IT organizations need some type of leadership structure to help guide the department and to interface at different levels within the organization. While it’s not common to hear about senior technical managers being good organizational leaders, it does happen. The early identification of individuals who have some of the above-mentioned attributes allows current leadership to groom those people for the future — an important step in making a company effective and successful.

Measuring Programmer Job Satisfaction

Are you satisfied with your job? Are you satisfied with where your career path is taking you? These are important questions, and I try to take time to think about this every 6 months or so. Its usually trivial to make a general statement rating job satisfaction: “Yeah I like my job.” or “My career is going nowhere.” But what factors influence programmer job satisfaction? How can hackers become more satisfied with what they do?

First lets break down the main indicators of job satisfaction, and look at how to measure satisfaction in each of those areas. In the next post in this mini-series I will write about ways to become more satisfied as a programmer.

Teamwork

According to Jeff Atwood, “The people you choose to work with are the most accurate predictor of job satisfaction I’ve ever found.” This rings true with me. Thinking back, during the times I was most motivated and happy with what I was doing, I was part of an excellent team of hackers. We worked well together. We bounced ideas off of each other. We were aware of each others strengths and weaknesses, and knew how to maximize the strengths while improving the weaknesses. We respected each others experience, knowledge, and all around hacker stardom. Well you get the idea…

Think of the best hackers you have ever worked with. Would they want to be on your team? If not, you are in trouble. If those hackers wouldn’t want to be on the team you are on now, its unlikely that your team will be able to attract other top notch hackers and its unlikely that you yourself are happy.

Good teams are made up of good hackers who work well together. Attracting top notch people is impossible without an environment that cultivates job satisfaction. So if the working environment doesn’t rank well for the satisfaction indicators below, it won’t attract good hackers, and therefore has virtually no chance of cultivating a good team. This is why the strength of the development team is the number one predictor of job satisfaction.

Quality of Projects

Intelligent people get bored doing the same thing all the time. Hackers are no different. If they are stuck with the same language, the same boring CRUD user interface, the same algorithms they learned in their first year programming, they will be unhappy. Most developers crave learning new things and being able to apply them. Difficult and challenging problems excite them.

Taking some time to think about the skills you have learned lately and the problems you have solved will give you a good idea of not only how satisfied you are in this area, but also how well you are advancing in your career.

Work-Life Balance

The hacker stereotype is to work incredibly long hours while surviving on Cheetos and Bawls soda. This death march method of software development isn’t sustainable and will take its toll over time, ultimately leading to burnout and job dissatisfaction.

Taking a look at the number of hours you are working will give some indication of how you rank in the work-life balance area. Many people on the track to burnout aren’t even aware of it, so talk to family and friends and ask them to help you gauge how well you are balancing work with other activities and obligations.

Bureaucracy & Politics

Some amount of bureaucracy and politics is unavoidable, but good management will be able to shield you from it to a great degree. The only time I found myself without it was during University, and that was more because of warped perspective than anything else. University bureaucracy was actually pretty bad, but I never thought of it as part of what I was doing. It just become something totally unrelated to programming; I thought of it more like paying the water bill or taking out the trash.

In general, happy, satisfied hackers are busy coding and are making progress towards a goal. As a group, programmers do not like to find themselves in endless meetings that accomplish nothing, ensnared in budget disputes, or without adequate resources to perform their best work. If projects are constantly stalled or held back by requirements that constantly change or are missing, management decisions, or lack of direction, hackers will be frustrated and unhappy. Worse, if programmers are left with nothing to do due to excessive bureaucracy and policy decisions, they will see that their skills are not being used and are therefore not valued. This leads not only to dissatisfaction with the bureaucracy, but also causes dissatisfaction with the amount of recognition and respect that they have.

Recognition and Respect

People who excel at what they do and are knowledgeable about a subject expect to be taken seriously and consulted with during decision making. This is as it should be. Management that disregards the opinions of their technical people or don’t consult them when it makes sense to do so will be left with uncooperative and dissatisfied developers when it comes time to implement an idea.

Have you been allowed to undertake difficult projects? Is your opinion sought out? Are your ideas taken into consideration? Are you congratulated for meeting important milestones? This are all good measures of your recognition and respect within a company. Are you often forced to implement something you don’t have any control over or disagree with? Are you often contradicted or marginalized by people who are less knowledgeable? (Careful with that one - make sure you are open to sound technical ideas.) These are indicators of dissatisfaction.

Compensation

This is one of the easiest factors of job satisfaction to quantify. Some quick research at online job boards gives a good idea of compensation packages for similar jobs in the same area. Discovering compensation packages for people in you own company can also be valuable information. Obviously if you are under-compensated you will not feel satisfied, and on the flip side if you are compensated well you rank as highly satisfied on this area.

After looking at and evaluating these criteria one by one, I have a much better understanding of my personal job satisfaction. It is easier to see which areas are working well and which I need to take action on in order to improve my own career satisfaction and general well-being. In two weeks I will cover steps to increase job satisfaction for each of the factors listed above.

In the meantime, what factors are important to you?