ThomasCantrell.com Tech Blog

In software development it’s often more important to figure out what people actually want, rather than how best to “engineer it.” According to Drucker:

There is only one valid definition of business purpose: to create a customer.

…

Because its purpose is to create a customer, the business enterprise has two – and only these two – base functions: marketing and innovation.   (p. 19, The Essential Drucker)

Although, I suspect Drucker could easily be accused of over-simplification, I love the simplicity. There are only two things, not twelve or twenty things as might be found in other business best-sellers. There are simply two functions: marketing and innovation.

Drucker does define these functions differently than one might think:

• Marketing: “The aim of marketing is to know and understand the customer so well that the product or services fits him and sells itself.” Marketing in Drucker’s definition has little to do with advertising, but rather focuses more on understanding the market.
• Innovation: Drucker does not just mean just research and development, but also innovation in how the product is built, advertised, and sold. Innovation, therefore, is not just a term for engineering, but it also what the rest of the organization does to built a product efficiently and run the very same organization efficiently.

As an software engineer, it is easy to concentrate on innovation. After all, making the whole process computerized and optimized is second nature to engineers. However, we have to remember that there is this other function: understanding the needs and desires of the market.

Marketing is important, but is not trivial. It is challenging. Sometimes customers and sales people can offer substantial amount of information about market demands. This information is extremely important, but it is not enough. Customers and their salespeople are often blinded by their own current perception of needs. It is like Ford’s famous quote: “if I asked the customer what he wanted, he would have said a faster horse.” We need to anticipate beyond the customer’s stated needs rather than simply looking at feature lists and requests.

Dilbert:

My experience is unless engineers and their management are careful, testing always gets the shaft. However, towards the end of the project it becomes clear that testing is still essential. Therefore it must be forced into the schedule. Once that happens there are two options: push back the release date or sacrifice your health.

I’ve worked on teams that chose each of those options. While neither is preferable, I would prefer work on the team that doesn’t cause health complications. However, it would be far better to hire people and schedule time for testing.

A few years ago I attended a talk given by Ross Anderson on the Economics of Security. In the talk, he asserted that “software companies should hire more software testers and fewer but more competent programmers.” However, testing is typically disconnected with marketing and sales revenue. Programmers, on the other hand, create the products and are directly connected to revenue. Therefore, companies are incentivized to hire few testers and many programmers. Then when testing starts getting the shaft, the only course of action is to ask the programmers to do testing in addition to their other responsibilities.

I’m packing for a business trip tonight and remembering this Dilbert:

I want to dress well, but sometimes I wonder if I should just pack some crazy ThinkGeek t-shirt to help my street credibility. If I look too “business like” can I be trusted?

After I read the article in the Harvard Business Review, I found this video online:

An Oldy But A Goody from Joel on Software:

[P]rogramming tasks take so long to task switch. I feel like when I have two programming projects on my plate at once, the task switch time is something like 6 hours. In an 8-hour day, that means multitasking reduces my productivity to 2 hours per day. Pretty dismal.

While this is eight years old, it is still extremely true. It’s good to remember really how inefficient it is to try to do multiple things while programming. 

In my world, my responsibilities are spread over enough topics that I can easily switch between things and take over a day to “task switch.” That’s why it’s really good to try to focus on one main thing. Now if I could only control outside interruptions…

One of the members of my engineering team died suddenly a few weeks ago. He was a brilliant engineer and only 21.

To respect the family, I am not posting much more information. However, I want still to take the time to talk about the contemplative journey caused by his untimely death.

As software engineers, we are passionate about technology. In embedded networking, we are passionate about the intricacies of the bits and bytes that make up communication.Most of our conversation is driven by technological talk.

Yet, we are foremost people. We are a community of workers, people who go home to their friends and family. We are a people that have dreams and goals, people who have a life beyond the bounds of work.

I remember the day a couple of weeks ago when his death was announced. After the initial shock had worn off, sadly there were still meetings and projects that were due. I tried to take time over lunch to reflect, but it’s hard to know how to reconcile the tasks of works with taking time to reflect on the engineer’s life.

As engineers, we build a competency in talking to each other about technical issues. However, it is much harder to talk about life and death with your co-workers. We look at each other not knowing exactly what to say. Life is much harder than bits and bytes.

From these sad events, I have been reminded of this firm conclusion: the value of a single human life dwarfs the value of the technology that we continuously dialog about.

As humans we tend to optimize our experience in ways we think will bring about the most favorable outcome. As workers we tend to work in ways which we enjoy and we believe we will be rewarded. As software engineers we tend to work in ways that we believe will get the best possible product to the customer and the best possible performance review for our work.

Software release processes take a long amount of time. They can take days, but often take multiple months or even years. However, from my own observation there is one easy way to slow down a software release: change the rules of the game in the release process.

For example, a software release enters the QA department with a certain set of features. While in QA, it is decided that an “essential feature” is missing. The software release is then ejected from QA to move to further development. Once the development is done it enters QA again. This time it releases, months late to the customer.

The same scenario could have played differently. The software could have entered QA. When the “essential feature” conversations, the software product proceeds through QA uninterrupted and releases. Then the “essential feature” could be added to the product and released in a seperate cycle. This way the customer gets the development they already desire, as well as the addition of the “essential feature” when it releases later.

What happened in the first example, is that the rules of the release were changed while in the release process. This caused the release to stall while every member of the team readjusted for the new rules. If the release had simply kept a consistent rule-set, then it would have gone out devoid of the “essential feature.” Once the product had shipped, a new process playing with the new rules would have commenced.

I believe that one of the most demoralizing things for an engineer to get stuck in a rule change situation. They hear that their code is going to ship in a few weeks. This causes them to rank up, and creates a sense of urgency. The urgency is driven by the reward of releasing their code to the customer. When the rules change, their code does not release. They then slow down to adapt to the new rule-set. However, now something is lost. They cannot find it in themselves to ramp up again for the next release. The light at the end of the tunnel has grown dim.

In conclusion, I believe that one key premise for software releases is change as little as possible towards the end of the release, especially when the product is in QA. It’s just dangerous to change the rules of the release game.