There is an infinite stream of problems to solve. However, finding one that’s worth working on is another matter entirely. Nothing comes for free, so we have to pick and choose what we focus on. Here’s some of the questions that I’ve asked during the course of my investigation.

The Ultimate Question: Should I Build This?

Q: Is this particular project worth my investment in time, effort, and money?

“Ultimate” has two connotations: last and most important. This question fits both of those; not only does it override everything else, but it’s only answerable after you resolve all of the underlying questions. However, it’s easy to lose sight of goals, so it needs to be asked first. This is where we can apply a fringe benefit of being a programmer: we’ll push it onto the stack and come back with an answer later. Asking this first gets us started though: it forces us to ask “How do we answer this particular question?”.

Benefits

Q: What do I get by working on this project?

Here’s my answers thusfar:

• Potential for profit. At first glance, this product looks like it should be able to make some money. More investigation needed here.
• Potential for huge profit. Actually, the chances of striking it rich selling to small bakeries seems pretty small. But stranger things have happened. This is a very minor (i.e.: unlikely) benefit but it’s nonzero.
• Potential for profit without spending lots of ongoing time. Everyone is limited in the amount of time they can spend on any given task. When you are directly converting time into money (which I do as a consultant) there’s a hard upper limit to the amount of money you can earn; all of your growth must come from increasing your per-hour rate, and eventually that will max out. Selling a product like this can circumvent that limit; the amount of money earned relates to the number of people who buy your product. This is potentially a much deeper pool than time. (Fun facts: there’s roughly 94,000 working hours in a lifetime, but 7 billion people on the planet right now.) See also: revenue per employee.
• Opportunity to learn new technologies. I can read all I want, but to actually know something I have to do something with it. Real-world projects give me the chance to solve real-world problems and get practical experience.
• Practice at building a business. Same as above, but outside of the technical realm.
• Helping a friend. Never a bad thing.
• Exposure to a new industry. New stuff to learn. New people to meet. New opportunities. One more basket in which to put eggs.
• Credibility and Reputation. I can say “I did this.” It’s action, and not just talk.
• Exposure. It’s good stuff to write about, and may get some good attention.
• Enjoyment. Building new stuff is fun. Having the results is fun. Making decisions is fun.

Costs

Q: What do I give by working on this project?

• Time. This will necessarily take away from other things I could be doing. Here’s a few: spending time with wife, family &amp friends, hobbies (photography, gaming, hiking), exercise.
• Opportunity Cost. Pretty much the same as “time”, but with a money angle to it. The time I spend on this project means that I’m not working on other projects I have on the backburner. The question becomes: which project has more benefits/profit potential? I think that this one is reasonably good.
• Ability to start a new project. Very similar to “opportunity cost” but specifically focused on an unknown future project that has a greater net reward. I don’t like starting projects that I don’t finish (though that happens far too often). This is more applicable to this project since it involves a friend.
• Effort. Building stuff often drains my personal energy, leaving less for other stuff. (See “Time”; it’s very closely related.)
• Money. This project should be pretty cheap in terms of actual cash outlay, but there may be some costs ahead of revenue. Right now I see graphic design and some hosting setup costs.
• Credibility and Reputation. There’s a downside here too. I’m not too worried about the fallout from the business failing, but there is potential for bad decisions and actions to negatively impact me.

Conclusions

A lot of this is incalculable, and thus hard to analyze. However, the costs seem to be quite manageable. Time is the biggest one, but it has to be spent somehow, and I think that investing it in something with a payout potential is worthwhile. There are some guaranteed intangible benefits.

As usual, the deciding factor is profitability, which is the next thing I’ll look at.

Pretty much all software is intended to solve a problem of some sort. The “problem” simply be “I want to be entertained”, but for “business” software it’s usually more specific. Ideally it’s tied to a profit-generating function. You’ll sometimes hear them referred to as “pain points”, “challenges”, “requirements”, or “opportunities”; they’re all really the same thing.

A few weeks ago I was approached by one of my wife’s friends. She’s opening a bakery here in Calgary and asked if I would be interested in creating some software for her. We met, discussed her needs, and I got a bit of understanding about her industry. From this I derived the major problem that I’ll focus on for the first round of development:

To be successful, low-volume / boutique bakers need to keep good control of their materials costs. However, it is difficult for them to do so, and so many do not.

This manifests itself in two ways:

1. Recipes are written to produce X number of finished units for Y ingredients. The bakery will require X*Z finished units per day, and so much put in Y*Z ingredients. However, if Z is not the values 2, 4, or 10, then calculating X*Z and Y*Z becomes relatively difficult and cumbersome. (The situation is made worse if you’re using non-metric units of measurement.) Instead, many bakers simply round up to the nearest easily-calculable value of Z, resulting in a lot of waste and expense.
2. To determine the per-unit cost of a product, you need to take:
   • The price of one purchasable container of each of your ingredients,
   • Divide that by the number of measured units in the container
   • Multiply that by the amount of ingredient in the recipe
   • Adjust (add) for waste and other miscellaneous uses
   • Repeat the above for every ingredient in the recipe
   • Sum the results for each ingredient together
   • Divide by the number of units in the recipe

   Repeat this process for every product sold (or potentially sold) in the business. Again, all this hoop-jumping means that bakers tend to not do this, and thus do not understand the costs of their products. Without knowing costs, you can’t know margin, profitability, efficiency, value, and opportunity.

Basically, the problem is one of mental math. Humans suck at it. Worse, they are often afraid of it, and so will go to lengths to avoid it. On the other hand, it’s basically the only thing that computers do, and they do it faster, cheaper, and more accurately than a human ever can.

This problem is well-suited to a technical solution: not only does it bridge a gap in human capability, but it’s one that’s extremely easy to build. (I basically just outlined the algorithm above). That means that it can be done without too much up-front investment in time and money. That’s important for determining whether it will make a viable business.

In addition to my “day job” as a software development consultant, I’m also evolving into a software entrepreneur. I want to sell products and not just my time. Over the past few years I’ve seen a lot of people accomplish the same dream (most famously the inspiring guys at 37signals). I’m going to try my hand at the same.

In concert with this, I’m going to document my development process, tasks, and ideas. I’m doing this for several reasons:

• To potentially inspire and instruct others to do likewise.
• To perhaps get some feedback from the development community.
• To document my processes for my own reference, benefit, and reflection.
• To build my cred by illustrating my thoughts and capabilities. (Better to show than simply to claim.)

I hope to go into a fair amount of detail — hence the “Play-By-Play” tag and title I’ll be applying to each of my posts. Please comment freely and enjoy!

I was just asked to give my top 5 qualities that I’d like to see in an IT Team Leader. Here’s what I came up with, in order of preference:

1. Dedication to excellence in communication: honesty, clarity, transparency, approachability, willingness to listen to the people closest to the problem at hand.
2. Ability to convince upper management of the realities on the current business & IT environment and the necessary steps for IT to help achieve business goals.
3. Familiarity and/or experience with strategies that make a successful IT department.
   1. One of the ways to demonstrate this familiarity is to have read & be able to discuss some of the excellent and important books on the subject: Peopleware, The Mythical Man-Month, The Inmates are Running the Asylum, Facts and Fallacies of Software Engineering. There are many others. I expect an IT team leader to have read and understand at least two of them.
4. Ability and drive to eliminate obstacles to the productivity of the IT team: a problem-solver.
5. Practical experience with technology and/or software development.

Marco and I have been talking a lot about the role of leadership in organizations. We’ve gotten on to a lot of different tangents, but there’s one important point I’d like to make out in the clear.

Marco’s Bro writes:

When I put someone in charge it’s because I want them to use their discretion — I believe they can be successful. I trust their judgment.

I expect that their team members will support them. I don’t expect unquestioning obedience or anything, but I expect everyone to realize that Leader Guy is, in fact, Leader Guy because I thought he was the best person for the job.

I know Marco’s Bro and, in real life, would probably accept most of his decisions. However, I disagree with this way of thinking in a general sense. My response to his statement goes like this:

What if you made a mistake? What if Leader Guy deceived you into thinking he’s more capable than he really is? What if he’s no longer as capable as he once was (personal problems, brain injury, etc)? What if he’s now out of his area of competence (see: the Peter Principle). What if you only rationalized to yourself that he’s trustworthy, when in actual fact you installed him because he’s dating your sister? What if your trust in him stems from his Harvard degree that his father bought for him? What if your boss chose you because he knew you’d choose That Guy, who happens to be his nephew?

Authority is a dangerous thing. When you trust in vested authority over other qualities then you put all of your eggs in the basket of the authority figure; your risk has gone up dramatically. That may turn out OK if the leader happens to be a good decision maker. However, thousands of years of history have shown us that following the leader doesn’t always work out well, and can often be disastrous. I’m sure everyone has been in a situation where they’ve had to accept the authority of someone who, on the face of it, shouldn’t have been given that power (I know that everyone in the U.S. has).

Marco and His Bro have stated that they don’t expect unquestioning obedience in the leader, but that when the leader has made a decision, they expect the rest of the team to go along with it, even if they think it’s wrong. This strengthens my argument against authority while at the same time cuts its legs out from under it. Yes, you want your leader to be taking the arguments of his subordinates into consideration. If, at the end of the day, he rejects them regardless of their validity, then they may as well not have been voiced in the first place. Both Marco and His Bro have said that if they’d heard of dissent escaping from the confines of the team and propagating up to their level, they’d tend to trust the leader and think of the dissenter as a troublemaker. Of course, that may true in a some cases, but this policy definitely puts a chilling effect on dissent that could be beneficial (or even critical).

In one of my instant messaging chats with Marco, the topic of religion (very briefly) came up. Religion is, of course, the ultimate in authority, both in a supernatural and in a real-world sense. Especially in monotheism, a deity has overwhelming power over its followers, who in turn have none over it. That deity, in turn “installs” its own hierarchy of people to act as a local authority on its behalf — at least according to the people in the hierarchy. Since these people supposedly have privileged access to the deity, they are effectively granted authority by the followers. Religion is particularly good at suppressing dissent, through everything from genocide down to making virtues out of trust and belief without evidence.

Evidence and reasoning are the keys to overcoming the risks associated with authority. They are the great equalizers, because Nature doesn’t care one bit about who has granted authority to whom — but with enough evidence and reasoning you can navigate the rules that Nature has put in place and use them to achieve your goals.

It may very well be that the chosen leader makes successful decisions because she applies the best evidence and reasoning to a problem. Ideally, this should be true in every case; you can make the best decision possible in the shortest amount of time when you don’t have to explain and justify it to others. But we all know that this doesn’t happen every time. Even if the leader has the best reasoning skills, she may not have the best evidence, and so her conclusions might be suboptimal.

This is why I reject authority that exists for its own sake. If an authority figure makes a decision, let the decision stand on its own merits, not on the position of the person who makes it. If it’s a good decision (based on the reasoning and on the evidence), then it’s worth supporting. If there’s an better one, let it be the course of action, regardless of who proposed it. If gathering evidence is too costly (and it often is), then it’s OK to go with the assumptions of the most “experienced” person on the team, but be prepared to reject those assumptions when the evidence contradicts it. Personal experience is a valid argument (we rely on it for a great many decisions), but it’s a weak one, and it should be overridden and/or augmented by objective evidence whenever possible.

Authority, at best, illegitimately takes credit for success. At worst, it leads to failure. Be skeptical of it at all times.

In many (most?) organizations, “being a team player” is code for “being nice” — which, in turn, is often code for “not contradicting anyone.” The problem with this is that it leads to groupthink and mediocre (or often just plain wrong) results.

I think that this Slashdotter has it right: (emphasis added by me)

I’ve worked for years in highly effective teams, and with success. I can tell you what made all the difference: The presence of equals to debate issues with, so that we could talk each other through the problems and emerge from the session with the feeling that we had defined better solutions. Perhaps we are all arrogant nuisances, but as long as we understand and respect each other we keep each other in check, and can function as effective team members.

The “respect among equals” also translates to “respect among people above and below you in the hierarchy” when such hierarchies exist:

• Listen to & consider what your boss says, but call him out on it when he’s wrong or hasn’t justified his assertions.
• Listen to & consider the objections of those below your skill and/or station, but correct them when they’re mistaken and clarify the reasoning behind your positions.

You should only be stating agreement when you reach the same conclusions based on the available information. If you don’t think you have enough information to defend a contrary position, it’s better to state that outright rather than agree by default. The lack of agreement, even without the presence of opposition, might be enough to show that the position is potentially unreliable.

Being a helpful member of a team means working to achieve the same goal as the other team members. It does not necessarily mean following the same process.

Update: Fixed the link to Slashdot. Sorry for that.

My old college buddy asks:

When you are trying out a new development tool, what do you look for to help you learn how to effectively use the tool? Is it help files, tutorials, white papers, samples, case studies, etc? Or do you learn best by participating in classes or through mentoring? Perhaps you only try to learn tools that are easily assimilated, and if so, what makes one tool easier to learn than another?

There’s a saying in the field of User Interface Design (computer and otherwise) that goes “there should only ever be one button: one that does exactly what the user wants.” Of course, this is hyperbole, but it does illustrate the theme of UI design: make the tool as easy to use / simple / natural as possible. A more usable product is the one that the user needs the least amount of thought to use and the least amount of initial training.

Accomplishing this is incredibly difficult, which is part of the reason why most user interfaces are absolutely horrible (the other is that most engineers don’t study usability, especially usability for mass audiences). Fortunately, this is getting better: Apple has made UI a sellable feature, and User Interface Design is now a bona fide field of research that gets attention from the builders (if you’re interested, you can start with Neilsen, Norman, and Tog, the current gurus of usability.

Now, to answer Graham’s question:

what do you look for to help you learn how to effectively use the tool?

Here’s my order of preference:

1. The tool should follow some natural metaphor, if possible. Ideally, the tool should behave as if it is an extension of my body / mind. This way, there’s no learning curve; you already know how to use it. Unfortunately natural metaphors are hard to come by in the decidedly un-natural world of technology, so most of the time this isn’t available. Still, I think it should be said.
2. If tool can’t follow a natural metaphor, then it should follow a familiar one. That is, it should try to duplicate one that already exists. This way there’s zero learning curve for users who already know the preexisting metaphor. There’s two big catches to this approach though:
   1. The old metaphor may not be terribly good to start with. Garbage in usually means garbage out.
   2. The old metaphor may not translate well to the new medium. QuickTime 4.0 is the poster child for this problem.
3. If the tool can’t be familiar then it should be self-describing. The means of accessing the features should be apparent (in fact, blatant). Available features should be displayed (rather than hidden) at the ready. This makes the learning time efficient: you are able to learn while you actually use the tool. A good illustration of this principle is the use of text rather than graphical icons to represent features: text describes the feature far more explicitly and accurately than a (tiny) picture.
4. If the tool can’t be (effectively) self-describing, then it should have description waiting in the wings for the initial learning period. Think of a tutorial, but one that teaches as the user uses the tool. Some modern games are great examples: every time that you encounter a new tool, feature, or technique they give you a brief explanation of how to use it, followed by some time to put it into practice. Play Half-Life or Portal with the commentary on to see the thought process behind this technique.
5. If you can’t do an effective tutorial mode, the next best thing is to have built-in (local) context-sensitive help ready at the touch of a button. There are three important factors to application help: relevance, speed, and connection to other topics (ie: lots of hyperlinks). This will help a user get out of a jam, but it may not do much to get them started in the first place.
6. If local help isn’t available, putting your help on the Internet (say, in the form of a FAQ) is almost as good as local help, although it’s not available if you’re disconnected (ie: on a plane). Internet help also lets you enhance help post-launch and get feedback/usage stats. If you get a good community behind the tool, they can potentially help with the help (with wikis & blog posts).
7. Examples can be useful; lots of people learn better from example than they do from a spec. The major problem with examples though is that they are necessarily of narrow focused and contrived. They may not be answering the questions that are being asked, and they certainly won’t be able to answer every question.
8. White papers and other wordy documentation are not nearly as useful as other forms of instruction; it’s harder to find the solution to a particular problem when it’s floating in a sea of flat text. Always remember that, as a rule, people don’t read.
9. Screencasts are appropriate for dynamic situations, where capturing the actual motion is important. Otherwise, video just becomes a very hard-to-use interface to the information being communicated; think of a book where the pages are turned at a fixed rate. Static text and pictures are better for most applications.

I’ll leave mentoring off my list entirely. I’ve never been a fan of (nor had much experience with) mentoring, because:

• I’ve always had a do-it-myself (and discover-it-myself) attitude.
• I’m often learning at the (b)leading edge of things; mentors with prior experience aren’t always easy to find.
• Likewise, people with more experience are often too busy to spend a lot of time mentoring. They’re adding more value by operating, especially if I’m able to learn effectively without their help (which, in turn, makes me more valuable too).
• I’m more anti-social than most. For work purposes at least, personal interaction is a means to an end, not an end in itself.

These don’t apply to many (most?) other people though, so they’re not a criticism of mentoring itself. Many people appreciate mentoring and find it valuable.

Lastly:

Perhaps you only try to learn tools that are easily assimilated

I certainly prefer easily-assimilated tools. A small learning curve makes the tool more efficient, which is half of the value equation. The other half is effectiveness, and that’s where poor tools can find their niche. If there’s no other tool that can do the work of one with a crappy interface / steep learning curve, then there’s not much choice in the matter; I’ll have to bite the bullet and learn / use it. But I’ll always be looking for a way out.

One stereotype is that teenagers are lazy and carefree, but this study says otherwise:

Canadian teens averaged 7.1 hours of unpaid and paid labour per day in 2005 – a 50-hour work week, virtually the same as that of adult Canadians aged 20 to 64 doing the same activities.

Personally, I felt a pretty big burden lift once I’d graduated college; there was no longer any project or paper looming in the near future which required weekend or evening attention. I now had legitimate time off. It was a wonderful realization.

Paid work is a big thing right now for teens too. Calgary has a tremendous labour shortage going on right now, and most of Western Canada (and perhaps further east) is in a similar situation. With demand for labour rising (taking wages along with it), people who wouldn’t work otherwise are drawn into the labour force… and a big part of that pool is teenagers in high school. I see them all over the place in retail jobs; some look around 14. That wasn’t the case when I was that age; finding a job was difficult (as there were plenty of out-of-work adults with experience who would work full-time for those low-end jobs) so most of my peers and I didn’t bother.

For me, the most distasteful part of the article is this:

Homework was the most time-consuming unpaid activity for teens, with 60 per cent averaging two hours, 20 minutes every day.

When you consider that most homework (especially at the high school level) is unproductive busy-work, this amounts to a huge loss of productivity and an increased stress burden. That doesn’t benefit anybody.

I pose for you a question:

Suppose that a client has contracted you to provide a service. You’re an expert in your field (at least, moreso than the client… that’s why they contracted you after all). The client wants you to perform some action, but you consider this action to be high-risk for the client. You tell the client that this is a bad idea, and that you should take a different course of action instead. The client refuses to agree; whatever their motivations, they insist on following their proposed course of action. Other service providers for the same client are syncophants; they raise no objections. Both the client and the other providers were hit with a problem of the very type you’re trying to avoid just recently… in fact, the client swore to try and avoid it in the future. There’s no guarantee that the problem will occur but past experience clearly says that it’s a bad idea.

Do you:

1. Attempt to save the client from themselves, and refuse to perform the action, even though doing so would make you appear to be a spoiler to the eyes of everyone else involved?
2. Let the client have their way, and play along with the rest. You’re not directly responsible for any failures, but if they do occur, the client may still try to pin the blame on you, and may ask you to work extra hard (at your own expense) to try and fix it.

I got in late last night without incident.

By the way, everyone needs to go and see Pushing Tin if they haven’t already.