Know Before You Count

"Know before you count" is a software development management principle simply stated by Gerald Weinberg as, "Before you can count anything, you've got to know something." He is talking about the many people who count things in software but don't know what they are counting. He provides a great example. We have data concerning what percentage of the software industry is involved with maintenance rather than development. But can we recognize maintenance? Is a "new" development that completely replaces an existing system considered maintenance or development? Is a "modification" to an existing system that doubles current functionality and removes 95 percent of old functionality considered maintenance or development?

When selecting metrics for your project, make sure that what you are measuring relates to what you are trying to achieve. This often entails using multiple metrics. Remember: Even if everybody is measuring something one way, that way is not automatically right for you. Think about your metrics. Since everything can be observed (and in most cases measured), carefully select what you want to observe (and measure).


References:
Stark, G., Durst, R., and Vowell, C., "Using Metrics in Management Decision-Making," IEEE Computer, September 1994.

Weinberg, G., Rethinking Systems Analysis and Design, New York: Dorset House, 1988.

Avoid The Impossible

This may seem like obvious advice. One the other hand, many projects commit to delivering their product on schedules that are 100 percent impossible. Barry Boehm has defined the "impossible region" as a relationship between the expected time to develop a product and the number of person-months (PM) to be consumed. Specifically, the elapsed time (T) from writing a software requirements specification to product delivery will not be less than 2.15 times the cube root of person-months, that is,

If you have a project that is estimated to take 5 person-months then this rule says that the project can't get finished faster than 3.7 calendar months.

Ninety-nine percent of completed projects have obeyed this rule. If you think you can do better then here are some ideas to revisit:

• Productivity and quality are inseparable
• Every complex problem has a solution

Reference:

Boehm, B., Software Engineering Economics, Englewood Cliffs, NJ: Prentice Hall, 1981.

Software Cost Estimation Methods

Numerous cost estimation methods are available commercially. Each is based on data collected from a large set of completed projects. Any of these methods can be used to generate ball park estimates for your software development project. To use them to generate more accurate estimates, you must tailor them to your work environment. This tailoring adapts the model to your type of applications and tools. It eliminates variables that are invariant in your environment. It adds variables that are productivity-influential in your environment.

Chapter 29 of Barry Boehm's Software Engineering Economics explains in detail how to tailor the Constructive Cost Model (COCOMO) to your environment. Similar tailoring guidance is provided with other cost estimation methods. You must fully embrace the spirit of such tailoring, or you will end up with dismally inaccurate results.


Reference:
Boehm, B., Software Engineering Economics, Englewood Cliffs, NJ: Prentice Hall, 1981.

Enneagram Test

A year ago I took an online Enneagram test. My top two personality types were:

1. The Achiever
2. The Perfectionist

Is it all mumbo-jumbo? Is it accurate? I don't know but that doesn't mean it can't be helpful. It is a good way to practice some self-reflection. It can act as an aid to give me some points to consider. You might find it fun to read the core values for each of the Enneagram types and consider which you most closely align with. Or try to develop your own core values. Doing so from scratch is a fairly difficult thing to do. There is nothing wrong from taking what you agree with from each of the Enneagram types.

Our beliefs change over time so it is valuable to test ourselves on occasion. I know my political beliefs have changed. The funny thing is that my friends noticed more quickly than I did. We hold onto labels even though our beliefs change and the labels become inaccurate.

Collect Data Unobtrusively

Data collection is extremely important to help with future cost predictions, to assess the current state of a project or organization, to assess the effect of a change in management, process, or technology, and so on. On the other hand, data collection in an obtrusive fashion -- for example, if it requires software developers to do considerable extra work -- is meaningless because its collection affects the data itself. Furthermore, data collected from developers who do not want to provide such data will likely be useless because it is unlikely that an uncooperative developer will provide meaningful data.

The best way to collect data is automatically, with no developer-perceived interference. Obviously you cannot do this all the time for all data, but you should automate data collection whenever you can. However, you must be careful not to cross any lines concerning privacy. Respect your employees privacy and be transparent about what and how you collect.


Reference:
Pfleeger, S., "Lessons Learned in Building a Corporate Metrics Program," IEEE Software, May 1993.

You Can Optimize Whatever You Want

Any project can optimize whatever factor of "quality" it wants to. In optimizing any one factor, other "quality" factors are generally denigrated. In a landmark experiment conducted by Gerald Weinberg and Edward Schulman, five teams of software developers where given identical requirements, but each was told to optimize something different: development time, program size, data space used, program clarity, and user friendliness. In all cases except one the programs produced by the teams where rated best in terms of the attribute they were told to optimize.

If you tell your people that everything (such as schedule, size, maintainability, performance, and user friendliness) is equally important, none will be optimized. If you tell them that only one or two are important and the rest unimportant, only the important ones will be addressed. If you give them an a priori relative ranking, the ranking may not be appropriate in all situations on the project. The fact is that there are trade-offs -- different trade-offs -- to be made constantly during product development. Work with your employees and help them understand your priorities and your customers' priorities.


Reference:
Weinberg, G., and Schulman, E., "Goals and Performance in Computer Programming," Human Factors, 1974.

Winter Reading Challenge

My local library is running a winter reading challenge. The challenge is to read five books that meet the following criteria between January 2 to February 29, 2020.

1. Listen to a Book



2. Teaches You Something New



3. Graphic Novel or Comic Book





4. First in a Series



5. In Another Time or Place



6. Book Club Recommendations (need to finish)



7. Author New To You



8. Outside Your Comfort Zone
• 
  
9. Under 200 Pages (currently reading)



10. Made Into a Movie (want to read)



11. Always Meant to Read
• 
  
12. Retelling of a Story





13. Set in an Imaginary World



14. Author of Color





15. Winter Setting
• 
  

The Ghost Map

The Ghost Map: The Story of London's Most Terrifying Epidemic--and How It Changed Science, Cities, and the Modern World by Steven Johnson
My rating: 5 of 5 stars

The story was great. You might be thinking, "I don't know about reading this. I've heard tons of 10 and 30 minute versions of this story. Is an 8 hour version worth it?" It is.

The last 20% of the book is the conclusion and it gets a bit off-topic. I don't think you'll really miss out on anything if you choose to skip it. There are good points made and discussed but if you're just here for the Ghost Map story then don't worry about it.

View all my reviews

Huge Differences Among Software Engineers

Productivity (measured by lines of code per person-month) can vary by as much as a factor of 25 from the most to the least prolific coder. Quality (measured by bugs found per thousand lines of code) can vary by as much as a factor of 10 from the best to the worst software engineers.

I'm sure you can see my bias in the words above that I think quality is more important than productivity. Unfortunately, I don't have data to see the intersection of those two measures. I suspect that there is a correlation between productivity and quality. But with a diminishing return where the act of writing more code prevents a person from thinking about the stakeholder's true intention or the ramifications of the new code.

As a manager, you have to encourage an optimal mix of productivity and quality. This isn't done just by focusing on a single software engineer. This is a whole team project. For example:

• If quality is down then consider requiring stricter code reviews.
• If productivity is down then consider lighter code reviews.
• If both are down, is your team overworked?
• If both are down, is your team in need of training?
• And, yes, sometimes you do have to single one person out and say, "Slow down. You are making too many mistakes." Or, "Speed up. You are spending too much time testing your code."
• I've heard both of those admonitions. They helped make me a better developer. They helped me find balance between getting stuff done and perfectionism.
• etc...

There is no right way to optimize a development team's productivity and quality. But there is a wrong way - deciding everything for yourself. No one has all the answers and even if they did it would upset the team members to have no input.

Talk to your team! Show them the data that has you concerned and ask for input. Share details about the budget to explain why sending a few people to the QCon conference in Tokyo isn't feasible but the whole team could go to KCDC. Find ways to combine team building with training.

Reference:
Sackman, H., et al., "Exploratory Experimental Studies Comparing Online and Offline Programming Performance," Communications of the ACM, January 1968.

Brooks' Law

Measuring a project solely by person-months makes little sense. If a project could be completed in one year by six people, does that mean that 72 people could complete it in one month? Of course not!

Suppose you have 10 people working on a project that is due for completion in three months. You now believe your are three months behind schedule; that is, you estimate you need 60 more person-months (6 months x 10 people). You cannot add 10 more people and expect the project to be back on schedule. In fact, adding 10 more people would likely delay the project further due to additional training and communications overhead.

Approximately a decade ago, I worked on a big project alone. I approached it as proof-of-concept and focused on getting everything to work. Since ensuring that everything worked was my goal I didn't devote a lot of time to good object-oriented programming practices... I'm not going to apologize for that. I still think I did the right thing to ensure that the project worked. Half of the work I was doing was testing another team's API and helping them get it right. However, the project managers really screwed me over by announcing the project finished when reality I had only finished testing the API provided by the other team. My boss put 20 people on the project to finish it in the next month. This could have been a disaster but she did an amazing job coordinating everyone's efforts. While all those people were helpful with writing documentation and performing testing while the code was being rewritten. It really came down to one person, Charles Forsythe, who took the largely procedural code that I had written and turned it into high quality OO code.

This project would have gone more smoothly had we intentionally planned to throw away my prototype. Also, it is generally a bad idea to try to retrofit quality. It is either a testament that my prototype was of high quality code just not of the required OO paradigm and/or that Charles' coding ability overcame the difficulty of performing a retrofit.

The point of that story is that from the outside it looks like 20 people were thrown at the project to finish in a month. In reality, 1 person finished the project in a month and 19 people cleared the way and focused on tasks that multiplied that 1 person's impact. By doing it this way, my manager avoided the additional training and communications overhead. If they all would have tried to develop code for the project then it would have failed due to Brooks' Law. This isn't a guaranteed way around Brooks' Law but it is a good way to reframe development problems.


Reference:
Brooks, F., The Mythical Man-Month, Reading, MA: Addison-Wesley, 1975.