Archive for March, 2009

C++ Round-Up

Sunday, March 15th, 2009

Here’s a round-up of interesting links I’ve recently come across related to C++:

dcc – A decompiler that outputs C code. It’s very restricted and the derivative project, Boomerang, appears to be abandoned. It’s hard to see how this could replace OllyDbg, but it’s an interesting piece of work.

Boost Memory Mapped Files – Boost has been solving core problems of C++ for years in a cross-platform way. I’m glad to have finally noticed this addition.

chSoftIntegration has a product that is a scripting language with C++ syntax. According to their web page, the scripting engine can read C++ source files. The idea of code re-use for scripting is interesting, but I suspect shortcomings exist. Also, with all the modules for Perl at CPAN, it’s hard to see the value.

Spec – An interesting idea of embedding specifications into C++ in a readable manner to support Behavior-Driven Development (BDD).


Rating Programmers

Saturday, March 14th, 2009

The Programmer Competency Matrix is an insightful tool to aid in objectively rating programmers in terms of ability when you have no history of results, like in an interview.

In computer science, however, they are missing Boolean algebra and discrete mathematics which are prerequisites for successfully working with data structures and algorithms. Also, in Software Engineering, I’d like to see levels of ability in risk management. Those two nits aside, this matrix is a handy tool to objectively rate interviewees or ranking software engineers by ability within an organization (e.g. associate, senior, principal, architect, fellow, etc.). Too often people are rated subjectively on the wrong criteria, for example: easy to work with rather than the results they produce and the abilities they possess. A tool like this can help you get over objective rating.

In my experience, titles do a have a function; they communicate to people outside your organization what you do and the level in which you contribute. Markup to the titles like senior in senior software developer, has little value. The meaning of associate, senior or architect is so subjective, they tell you nothing. When I look at a business card and I see the title senior software developer, I ignore the prefix (e.g. senior) and only assume they work with software. This is a side-effect of pervasive subjective ratings and a lack of tools to objectively measure ability.

When selecting a method to rate or rank, there’s a temptation to make it so clear, you don’t have to think. The idea is the perfect solution will arrive at the same conclusion every time. However, the best solution frequently arrives at the right conclusion much of the time. Implementing a black-or-white rating scheme invites people to “game it,” or put another way, algorithmic rating invites sub-optimization. A great example of inviting sub-optimization is in a BusinessWeek article, “Data Mining Moves to Human Resources” (via Slahsdot). The articles describes how Cataphora uses algorithms to rate employees, using behavior and communications. Though Cataphora provides objective criteria, it’s rigidly applied. Today, an algorithm can’t holistically measure effectiveness of two different programmers in a meaningful way. Once people know the metrics, and the metrics will be figured out, people will sub-optimize their work, prioritizing conformance to the metrics over achieving business goals.

Imagine if programmers were rated on clarity and volume of their communications. Suddenly you would have programmers spending significant time writing email and documentation. While that’s not entirely bad, email and documentation don’t directly contribute to revenue as code does. Since communications are overhead — necessary, but not directly contributing to revenue — you want the smallest amount possible that gets the job done right. Motivating workers to get a check on an HR form is dangerous, especially with knowledge-intensive workers, as they will reverse-engineer any system to figure out how to do a good job.

My belief is managers can be objective in rating employees without losing a holistic view that is tied to company objectives. While I believe HR can create a framework to capture individual manager’s rankings and ratings on employees and candidates, no one in the organization can successfully resort to using a single set of metrics to effectively rank everyone. Individuals are too individual to be measured in a rigid manner. Being objective takes thought, but when done right, so does every other part of your job. When I hear about a process that removes critical thought, like in the BusinessWeek article, I see trouble. Use objective criteria that make sense, but apply them thoughtfully.


Time Estimation in Software Development

Sunday, March 8th, 2009

Time estimation of software development efforts is usually wrong, often underestimating the time required to complete tasks. Here are some contributing factors leading to under-estimation:

  1. Assumption of full 8-hour days to write code
  2. Incorrect or changing scope
  3. Imperfect knowledge of the problem
  4. Unanticipated changes in priorities (e.g. emergencies)
  5. Budgeting time to test, but not time to close issues found in testing
  6. Failing to time-box research
  7. Overoptimistic, assuming nothing will go wrong

Assumption of a full 8-hour day to write code

Your day will have times when you are not working. Paper work, e-mail, meetings, set-up work such as configuring test environments and that extra 20 minutes taken for lunch all take time out of the day for development. Additionally, developers suffer significant penalties due to interruptions that have large expenses as developers get back up to speed. A good first assumption is 20% overhead, or 8 hours out of every 40 is spent on overhead tasks typically involving communication.

Incorrect or changing scope

Perhaps you missed some steps that need to be done? This is why developers like to have requirements written down. It amazes me how infrequently requirements are written and when they are, the statements make glaring assumptions. Additionally, people change their minds, the economic environment changes or new opportunities arise and suddenly, the scope of work changes, often increasing the scope of work (though not the time to deliver).

Imperfect knowledge of the problem

Teams waste work because people skipped the part where they are supposed to figure out what the problem is, because it’s more fun to code. There are many ways to understand the problem: use cases, design documents, user stories, requirements analysis or simply talking to the customer. A common factor in success is a repeatable means to refer to the problem that everyone can go to and arrive at the same conclusion. Though it sounds easy, it’s surprisingly hard and time-intensive to communicate in such a way that eliminates assumptions.

Unanticipated changes in priorities (e.g. emergencies)

People organize for the common scenarios, i.e. business as usual. If everyone knew and was adequately prepared for an emergency, it wouldn’t be an emergency. Those who try may be seen as wasting time and resources, which can be true. Sometimes, short-term business needs re-allocate resources and the best thing to do is actively communicate upwards the effects of changing priorities before, during and after the change. How do you do communicate before the change? I communicate time estimates with the explicit assumption of unchanging priorities. Once they change, I state the effect. You can’t assume everyone knows the effect of the change or even knows about the change.

Budgeting time to test, but not time to close issues found in testing

It may take a week to go through all the tests, but what if bugs are found? First the bugs have to be reproduced, documented, fixed, verified and then, ideally,  the tests start from the beginning and the cycle repeats. Typically, the larger the number of bugs, the more test cycles needed, though complexity of fixes is a better indicator. How many test-fix cycles will you need? It’s a hard question to answer and keeping your software quality up and your technical debt down is the best way to keep the number of test cycles low.

Failing to time-box research

Some problems are not straight forward. Many solutions may need to be evaluated or sometimes you need figure out a new way of doing something. You can generalize developers into two categories: production and prototype. Production programmers will usually take much longer, because they want the ideal solution. Prototype developers take much less time, but their solution usually has limitations. Time-boxing research is a way to set expectation with developers. If you know that developer’s ability, time-boxing is a coarse way to control quality of the design and implementation.

Overoptimistic, assuming nothing will go wrong

Helmuth von Moltke wrote, “No battle plan survives contact with the enemy.” If you account for that, perhaps by giving yourself a time buffer for problems, you can absorb many, but likely not all, setbacks.


On a high-risk project, I convinced the team to account for all of the above when estimating effort for software development. We easily met our goals, so easily, that management accused the team of padding the estimates. Under pressure, we went back to the old way of estimating (essentially ignoring all risk). Projects were delivered late and management changed it’s grumbling from “lazy, padded estimates,” to “lazy developers need to work harder.” In software development, there is a tendency to shoot the messenger (i.e. developer) for accurate estimates. Software is expensive and many companies would rather go into it not knowing that.


No Kindle for Me

Sunday, March 1st, 2009

The Kindle 2 is tempting, but I like to own my books. With the Sony Reader or Amazon Kindle, I can’t sell my books.  If either Sony or Amazon goes away, I lose my books. That doesn’t make sense. Gizmodo has an interesting article describing how leasing books and denying the first sale doctrine may be illegal, I’m not hopeful. I’m old fashioned, if I buy a book, I want to own that book and have use of it for the rest of my life. With the Amazon Kindle or Sony Reader, I have it for the life of the respective company or the hardware, whichever expires first.

If I was licensing the book from the publisher and the media was available on all hardware, I’d be less concerned. Even then, though, publishers could go under and sometimes rights holders of media can’t be bothered to keep licensing their copyrighted material. Also, the loss of arbitrage and secondary markets in a license-only world would be troubling, but not a deal breaker for me. Buying the same content again to be usable on the technology du jour is a huge deal breaker.

Drop the DRM, open the format and I’ll buy a kindle.