iPhone 3Gs

June 20th, 2009 by Edmond Meinfelder

Like many others, I got a new iPhone 3Gs  yesterday.

After getting used to the interface, I noticed something: there is no way to automatically set the volume down or switch from ringing to vibration during key times, e.g. meetings or bedtime. I looked for an application to fix the problem and … nothing. A quick look at the iPhone developer website revealed the reason:

Global system volume, including your application’s volume, is handled by iPhone OS and is not accessible by applications.

It’s a security issue. Apple does not want applications breaking the core functionality of the phone and, presumably, the company doesn’t want to inspect every application for functionality as it does for decency. (Arguably, we’d get more benefit if Apple did the reverse.) This is a solvable security issue: have the application request from the user, the privilege of setting the system volume. OS X does this on a less granular scale now, when installing system software, users receive prompts for administrative privilege. When this happens, the operating system is asking users if the application can application administrative access.

To me, it’s more of the same “let them eat cake” mentality that’s too common in consumer electronics. Apple is saying, “We’re not going to fix the problem of iPhones ringing in meetings and you’re not going to either.” It’s frustrating. When I am in a meeting or asleep, I don’t want my phone to ring, so now I must either keep it by me all the time (on vibrate) or remember to switch ringing on and off at the right times (unlikely). With a little forethought and action on Apple’s part, anyone could fix this problem.


C++ Round-Up

March 15th, 2009 by Edmond Meinfelder

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

March 14th, 2009 by Edmond Meinfelder

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

March 8th, 2009 by Edmond Meinfelder

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

March 1st, 2009 by Edmond Meinfelder

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.


Body Language

February 25th, 2009 by Edmond Meinfelder

Not everyone says what they mean, but according to Navarro and Karlins in What Every Body is Saying, our bodies are more truthful. Apparently people are prone to look at faces first for meaning when they should be looking at the feet, torso, arms, stance and posture. The central idea of the book is that our physical actions are governed by our limic system which controls the fight or flight response. If you didn’t like someone, you might unconciously lean away or turn your feet away from them. If a person puts you at ease, you may find yourself copying their posture, e.g. crossing your leg in the same manner they did. Recently, I saw someone report a delay to a manager. The manager suddenly dropped their cell phone, thinned their lips and looked to their left for 10 seconds, a clear indicator of the manager’s emotional state. Because it was a departure from the previous behavior and occurred in response to a statement (“the project will be late”), I could make a compelling case that the manager was upset even though no displeasure was registered verbally. The book trains you to use body language as a way to make educated guesses on the emotional state of people. You can’t tell if people are lying, but knowing if they are anxious, upset or pleased can help you communicate effectively. The book is well-written, contains copious case studies and citations which makes interesting and credible reading.


Do Cubes Make Sense?

February 23rd, 2009 by Edmond Meinfelder

The people who need solitude the most, software developers, quality engineers, etc. are working in noisy cubes with constant interruption. Meanwhile, managers, whose job is to primarily communicate and organize, have offices. Yet managers spend much of their time away from the offices, communicating to people not in their offices.  Developers who would benefit from doors to close, rarely get them. The logic is managers need doors to close to discuss private matters. In my experience, if I am closing my door a lot, I’m doing something wrong. Why businesses should give developers offices is well-covered in Peopleware, yet most developers remain in cubes.

Cubes made sense, once. In the age of mainframe computing, your IBM 3270 was not portable as it was hardwired to the server. To work, programmers needed to be at their desks. The idea of programmers working from home was not feasible early on. Most everyone in the data processing industry had a cube. Eventually we got modems, SLIP, PPP, broadband connections, laptops and now, wireless. Today, where you can sit, you can work. Beds, coffee shops, couches, air ports, trains are all potential work locations. Why do we still have cubes?

Some people like a small space to personalize that is separate from their home. For some working from home is more distracting than in a cube. Some people like the distractions and opportunities to socialize with co-workers.

Many larger, slow-to-change, businesses have yet to figure out that cubes are overhead and a waste for those who don’t want or need them. Sometimes, corporate culture can be slow to change.

Companies fear that people not co-located won’t work together effectively. I’ve had employees work from home and from the other side of the world effectively. If you have competent people that are motivated, you can trust them.

What would I like to see? A quiet-as-a-library work area, with desks, chairs and couches. Near the work lounge would be numerous small rooms for teams to collaborate. Adjacent to that would be a large space where people could talk, have many white boards, sit down, eat and be noisy. However, some people may need or want a cube – give it to them. However, split some of the cost savings for those who choose less expensive options like working from home or shared work areas. I don’t see a problem with cubes, but if less expensive options exist with equal promise, why not try them?

Ironically, though, after we transition to shared work areas, cubes will become a a luxury. Imagine that.


Be a Leader

February 13th, 2009 by Edmond Meinfelder

A friend gave me invaluable advice on management: Be a leader. Managers delegate tasks, but leaders are the people you turn to when you have a problem. You want to go to a leader because you know they will help.

To me this means, I have to be:

  • Competent
  • Clear
  • Humble
  • Trusting
  • Consistent
  • Honest

And one more that’s different from the others:

  • Creative

More frequently than you’d like, you’ll be caught between upper management your team. On the line will be your team’s goal to do the great work of which they can be proud. Being creative helps you see the middle road between the black and white areas. In other words, the solution that you didn’t think of right away that gets everyone to where they want to be.

Creativity is different, because it’s the only one you can’t learn or practice. You have it or you don’t, like the ability to learn pointers – not everyone has it. However, the other traits you can learn through practice. Many people go very far that were competent, humble, etc. but not creative. Because rather than having subordinates, these leaders had a dedicated group of supporters who were always there for their leader. It’s arguable that a slightly flawed leader is easier to follow, because you feel that leader needs you.

“Be a leader,” was the most succint and helpful advice I’ve ever received.


Performance and Knowledge-Intensive Work

February 8th, 2009 by Edmond Meinfelder

Sometimes your reports don’t work in an optimal fashion during their work day. People don’t come and go at the same time and some arrive very late. Not everyone works exactly 8 hours every day. Sometimes people work together on a task best suited to one person.

Occasionally, managers try to raise productivity by optimizing how people work on an individual level. Hard rules, like “everyone in the office by 8 a.m.” or “no web browsing not directly related to work,” are what I call top-down productivity approaches and, in software development, I’ve never seen any returns other than increased turn-over of staff. Bottom-up approaches, getting staff to volunteer improvements, works better. Near-universally, people want to make positive impacts and will try, if given a chance. Structure opportunities for people to improve their performance. A simple question may suffice, “How could we deliver more features in the same amount of time?” If the initial answer is, “We can’t,” then keep asking questions and continue to challenge them. Most will rise to a challenge.

Management must be concerned with performance, but past the workflow-level (i.e. where are the bottlenecks constraining my resource capacity?), it’s a mistake to try to organize how individuals perform tasks delegated to them. If you were managing a team whose sole job is to clean floors and there is one proven way to do the job efficiently, then directing people on how to work makes sense and saves money. However with knowledge-intensive work (e.g. software development), there’s frequently countless ways to do any task. Though you may know a wonderful way, is that the way your report can best implement and maintain? Likely not, if they did not pick your preferred method. It’s a trust issue – your reports were hired to think and if you trust them do their jobs and avoid doing theirs for them, they will be happier and more productive.


How Large Is a Short, Int, Long or Long Long?

February 1st, 2009 by Edmond Meinfelder

How many bytes are in an int or a long? Most think int type sizes vary with platform between 2 or 4 bytes while the long integer is 4 bytes regardless. Though that can happen, that’s not how the C standard defines int type sizes.

The C standard allows the int types to vary as everyone expects, but C only defines a minimum size. The short integer must have at least 16 bits. Type int must also have at least 16 bits and be at least as large as the short integer. The long has a minimum of 32 bits. C99 introduced the long long type which has a minimum of 64 bits. For each type, the C Standard defines no upper boundary. Here’s a quote from the C99 draft standard:

The values given below shall be replaced by constant expressions suitable for use in #if preprocessing directives. […] Their implementation-defined values shall be equal or greater in magnitude (absolute value) to those shown, with the same sign.

The previous passage is talking specifically about the definitions in limits.h, which, in the standard, have the following definitions:

minimum value for type short int: SHRT_MIN -32767 // −(152−1)
maximum value for type short int: SHRT_MAX +32767 // 152−1
maximum value for type unsigned short int: USHRT_MAX 65535// 162−1
minimum value for type int: INT_MIN -32767 // −(152−1)
maximum value for type int: INT_MAX +32767 // 15−1
maximum value for type unsigned int: UINT_MAX 65535 // 162−1
minimum value for type long int: LONG_MIN -2147483647 // −(312−1)
maximum value for type long int: LONG_MAX +2147483647 // 312−1
maximum value for type unsigned long int: ULONG_MAX 4294967295 // 322−1
minimum value for type long long int: LLONG_MIN -9223372036854775807 // −(632−1)
maximum value for type long long int: LLONG_MAX +9223372036854775807 // 632−1
maximum value for type unsigned long long int: ULLONG_MAX 18446744073709551615 // 642−1

The key point is the C standard defines minimum values and your platform may have different values than what the standard states, but if so, the values must be larger. The safe way to determine the minimum and maximum values for all C types on your platforms is to use limits.h, e.g.:

#include <limits.h>
printf("Minimum value for a signed int: %d\n", INT_MIN);
printf("Maximum value for a signed int: %d\n", INT_MAX);

In C++, rely on limits rather than climits. In C++, limits defines a template class, numeric_limits, specialized for each of the fundamental types (e.g. int, short, float, double, etc.). To determine the range of possible values in C++ using numeric_limits, for an int, you would do the following:

#include <limits>
#include <iostream>
using namespace std;
cout << "Minimum value for a signed int: " << numeric_limits<int>::min() << endl;
cout << "Maximum value for a signed int: " << numeric_limits<int>::max() << endl;

Good references on the topic are Harbison and Steele’s C A Reference Manual and Steve Summit’s C FAQs.