Interesting article:
Jason Fried talks about hiring at 37 signals.
Archive for the ‘Business’ Category
Never Read Another Resume
Monday, June 28th, 2010Risk Aversion
Wednesday, June 10th, 2009I was recently accused of being risk averse. I would readily concede that I am more risk averse than many. But the accusation has given me cause to reflect. I started by looking up a definition of risk averse:
Wanting to avoid risk unless adequately compensated for it; the attitude of most investors. For example, if two investments have the same expected return, the one with lower risk will be preferred. A riskier investment has to have a higher expected return in order to provide an incentive for a risk-averse investor to select it.
I don’t think that when I was accused of being risk averse the statement was intended to be quantitative. Rather I think it was a qualitative statement. I understand that the usage as a qualitative statement is a popular one that has something of a negative connotation. I can certainly see how never being wiling to take a risk is a problem. But I don’t think that’s me. We should be clear about the distinction between not being able to take risks and the desire to understand risks and make decisions accordingly. Not paying attention to risks seems reckless to me. This is particularly true when making decisions about a project and managing that project. From a project management perspective, understanding and mitigating risk is usually seen as a necessary part of the process.
I think of risk this way:
1. Understand the risk.
2. Make the best decision about the risk (the unknown) based on the things that are known.
3. Take precautions and monitor the risks.
If I go back and try to evaluate the original statement, that I am risk averse, I’m no longer sure I agree. I think that if I saw sufficient return for the higher risk I would not hesitate to take the risk. It pushes the whole thing in the direction of values. I suspect the person who made the accusation had very different values (and hence different understanding of the expected return) than I did.
The one thing that I can definitely say that I have learned through this thought process is how to communicate risk. I have found that rather than putting it in negative terms, it is better to put it in positive terms in the other column. In other words, rather than a list of pros and cons for two sides of a decision, I’d now rather put only pros. A con is essentially a pro in the other column. And wouldn’t we all rather be a pro than a con?
Business Users and Rules Engines
Tuesday, February 26th, 2008In the Software Development Times dated February 15, 2008 there is an article by Jeff Feinman called “Business Rules Undergo Change”. He says this in the article: “…providers are starting to offer tools and processes that allow business people to directly create and maintain business rules.” That statement caught my attention, and here’s why.
I’ve seen this before. The claim is easy enough to make, but the execution is often much more difficult than anticipated. Having business users writing rules is good for developers because maybe people will realize that the logic thing is actually non-trivial and often down-right hard. Developers already know this of course. We’ve known for a long time that writing the code is not the hard part–its figuring out what it needs to do that is hard. And if the business rule is straight forward, it’ll be all the exceptional cases that get you. I find that it is often the developer who helps the business user think through the logic of what it is that they actually want. In my experience I find it rare to find a business user who can clearly formulate the process that they use every day. So it is the developer who helps the business user figure out what the rule actually needs to be and not the other way around.
This is not meant as a criticism of business users. It’s meant more of an affirmation of the complexity of software development. You can write rules engines that are easy enough for non-developers to use. That has been done before. But it is another thing entirely to expect a business user to have the mind-set needed to write rules that software can understand. There’s the abstract thinking, attention to details and somewhat ruthless adherence to logic that gives someone the predisposition to be a developer. And there’s also habit–it is something that we do every day. But this isn’t something that most non-technical people need to do an awful lot.
It is for these reasons that I am skeptical of the idea of general purpose end-user rules engines. There is however one area where this kind of thing might work. And that is in very particular kinds of applications where the rules are limited to a very narrowly defined set. The more narrow the focus of the rules engine the more accessible it might be to business users. But then it starts looking more like customization options and less like a rules engine.
Company In Balance
Wednesday, January 31st, 2007In a meeting at work a few weeks ago, one of the executives told all the staff that without the customers we would not have jobs. My immediate thought was, “Well, you might not have a job, but I’m pretty sure that I’d have a job somewhere else.” But aside from my snide thoughts, there is, in my opinion, a major flaw in this kind of thinking. In short, that flaw is to elevate the customers above the employees.
Going back in time to a meeting at another company many years ago, a different executive said something that makes a bucket load of sense, and it has stuck with me ever since. He said that there are three parties in a company, the owners, the employees and the customers, and all three parties need to be happy. Each party might have different needs and might be looking for different things from the company. But those things all need to be kept in balance and goals of all three parties must be met over the long run for the company to be successful. So to say that a company is all about the customer or is all about the share holders (owners) is either marketing drivel or is to put the company out of balance.
In my experience, companies tend to overemphasize the needs of the customers or the owners and usually at the expense of the employees. It might be expedient to highlight one of the parties for some particular reason, focusing on customers for a huge sales push for example. But in the long run the executives of a company should do nothing to undermine the standing of any of the three primary parties: the owners, employees and customers. Maybe it is idealistic to think that a company could actually value all three parties equally. It doesn’t really seem that hard does it? And wouldn’t it be great to work somewhere that did not treat the employees as second class citizens?
Developer-Customer Agreement
Thursday, December 28th, 2006The following quote is taken from page 325 of Rapid Development by Steve McConnell. The author is talking about helping the business users understand the complexity of the requirements gathering process. And this is presented as a suggested agreement between developers and business users (customers).
We have all tried to capture every important requirement in the requirements specifications, but there will inevitably be gaps, which the software developers will need to interpret on their own. On a typical project, there are hundreds of such gaps, which makes it impractical for developers and customers to confer about each one. The vast majority of those gaps are typically resolved by the developers without the customer even becoming aware that an ambiguity ever existed.
In some cases, the customer will have a strong feeling about how an ambiguity has been resolved and will want to have it resolved differently. This happens to a greater or lesser degree on virtually every software project. To the extent that such ambiguities are clarified by the customer later in the project to mean something different than what the developer assumed, there will probably be negative impacts to cost or schedule or both. The developers will try to design the software to minimize these negative impacts, but we all know from long experience that this unpleasant feature of software development is unavoidable. We will all try to remember when that happens that it is unavoidable.
As developers, we will try to be responsive to the customers’ needs and create a solution that satisfies the customers’ desires with minimum disruption to cost and schedule. As customers, we will try to remember that developers have done the best job they could in interpreting the gaps in what we have told them.
How sensible! How rational! How unlike the business world that we usually work in! Actually I have to say that my current employer is more understanding in this regard than many of the places I have worked in the past. I like the idea of an informal agreement to help mediate between technical and non-technical folks.
The World Is Flat
Thursday, December 7th, 2006Yesterday afternoon I was part of a conference call with some system integrators who will be doing work for my company. Those system integrators were in Tel Aviv which presented time-zone, culture, and language difficulties in addition to the usual issues with speaker phones and multiples lines on a conference call. This meeting reminded me of a book about technology and globalization that I read a couple months ago. The book is The World is Flat, by Thomas L. Friedman.
The World is Flat is an interesting book. I’d recommend it for anyone with an interest in technology, business and globalization. The author tells a lot of stories, which are presented as evidence for the points he makes. The book was a bit on the long side. It was all interesting, just a bit redundant at times. The main point of the book is that the world is changing, primarily due to technology. Of course, that last statement is much too simplistic, but that’s kind of what the point of the book boil down to. The book is more descriptive than prescriptive—the author seems more interested in persuading you that the world is flat than helping you figure out what to do about it.
My biggest criticism of the book is that it seems a bit overly-optimistic at times. For example, my experience on the conference yesterday was much more difficult than it needed to be. I think that language, culture and effective communication have a huge impact on the ability of global partners to do business together. Even motivated parties who are positively inclined to cooperate globally might have difficulty in understanding and being understood. I don’t think this takes away from anything said in The World is Flat, but it seems to me that there needs to be a lot more thought put into making a global marketplace work smoothly.
Am I a Joel Groupie yet?
Thursday, September 21st, 2006Joel Spolsky had a interesting series of articles on hiring developers:
http://www.joelonsoftware.com/articles/FindingGreatDevelopers.html http://www.joelonsoftware.com/articles/FieldGuidetoDevelopers.html http://www.joelonsoftware.com/articles/SortingResumes.html
That’s three blog entries in a row that refer to Joel’s blog. Am I a groupie yet?
Micro ISV – From Vision to Reality
Saturday, August 26th, 2006I have just finished reading Bob Walsh’s book, Micro ISV – From Vision to Reality. The book is for someone starting a small software company. ISV stands for Independant Software Vendor. And by small (micro), we mean one or two people.
My impression of the book is this: one third of the book is screen shots of web pages, one third is interview transcripts and only one third is in the authors own words. (I didn’t count the pages, those percentages are just the impression I have of the book.) I’m not sure what I think about the format. It is certainly different, and if one were starting a Micro ISV, much of the content would prove useful. And the author brings all the information together and organizes it in a helpful way. I guess what bothers me is that it doesn’t seem that we really get much of the author’s own story. Also, web sites come and go and the majority of the book’s content will quickly become stale.
If you plan to start, or are in the process of starting your own software company, you would be well served by reading this book. Otherwise, I wouldn’t recommend it.
Eric Sink on the Business of Software
Tuesday, August 22nd, 2006About a month ago I finished reading Eric Sink on the Business of Software and was going to write about it here. But my son, Caden, was born before I could finish my review, so here at last it is.
The book is comprised of a collection of essays from Eric Sink’s blog. But don’t let that fool you into thinking that the book is less valuable for it. If you want to save a few bucks, just check out his blog and you can get most of the book online. But the material is well written and the content is both useful and entertaining so I am glad that the author gets some payment for his work.
To sum up the content I would say that it attempts and succeeds at helping techies see the dark side—the business side of running a software shop. While the focus of the book is mostly on the business of a small ISV, many of the principles apply in corporate IT shops such as the ones I have worked in for most of my career.
The book is broken into four sections: Entrepreneurship, People, Marketing, and Sales. And while those topics might sound boring to most software developers, the author explains things in a way that I found interesting and enlightening. For example, I found the financial information about stuff like balance sheets, and income and cash flow statements to be educational but I didn’t feel like I was listening to a lecture.
In chapter eight, the author makes a distinction between programmers and developers. He then goes on to say that a small ISV needs developers, not programmers. This is also true for small companies with limited resources in their IT departments. I would recommend this book to anyone working in a small group of developers. If you work in an ISV, I’m sure you’ve already read the book at least twice. 
Here are a few quotes from the book:
On the benefits of reading:
“Reading is not a place to find the answers to your problems. On the other hand, reading is a way to learn the background that can help you figure out your own answers.” (Page 65)
On Self Awareness:
“People who are committed to constant learning are people who know what they don’t know. They know their own weaknesses, and they’re not insecure in talking about them.” (Page 103)
On Making Mistakes:
“We all screw something up from time to time, but we don’t always learn from the experience. Why not? Quite often, the reason we don’t learn from a mistake is because we’re too busy trying to hide it.” (Page 128)
On Technologies:
“You need to focus on problems to be solved, not on technologies to be applied.” (Page 138)
“Someday I will learn that nobody else cares about my technology whims. ” (Page 173)