Eric Sink Says “Don’t Fake the Plural” – But I’m Not So Sure

In his latest Business of Software column, Eric Sink focuses on what he calls Micro-ISVs – software companies comprised of one person.

In the article, he urges one-person companies to not use the term “we” self-referentially in their marketing materials; rather, small companies should own up to the fact that the whole company is comprised of one person.  Here’s Eric’s take on the matter:

Don’t fake the plural
I don’t think micro-ISVs should try to hide the fact that there is only one person in the building. Conventional wisdom says that even a one-person company should use the word “we,” but I think it often ends up looking silly.
This seems particularly true today in a world where weblogs have become so popular. More than ever before, companies like to see a glimpse of the person behind the product. The result is that a lot of one-person companies are speaking in the first-person plural while a lot of larger companies are speaking in the first-person singular. Doesn’t this seem kind of weird?

Now, since I’m in the process of launching a micro-ISV, this article  – and more to the point, this admonition of “don’t fake the plural” – was of interest to me.

I have a slightly different take on this – I think that whether or not you present a corporate image that suggests a multi-person company depends upon your product and market.  For example, Eric mentions that Steve Pavlina seems to do just fine being the only person behind Dexterity Games, and that Nick Bradbury has done great things with Bradsoft, but I have to wonder – would the marketplace so readily accept a one-man show that was producing something more business-critical, like an HRIS or MRP system?  My gut and my personal experience tell me that this is not likely.  Steve and Brad are making games and newsreaders, respectively.  If these guys folded up their businesses overnight (which is the real fear people have about one-man companies), how big of a negative impact would it have on their clients?  Probably very little.  I say this not to belittle their accomplishments, because I admire them both very much.  I mean only to point out that they are  offering products that are non-mission-critical to anyone (which is probably a smart move on their part).  By contrast, I build custom business tools that companies use to either make money or save money – if I were to go belly-up there is potential for damage to my client’s businesses.  Now, since I work primarily with small businesses, a lack of scale works in their favor – they’re small enough to handle the business on pure hustle in an emergency.  But what if a one-man shop wants to grow up a little and do business with Fortune 1000-sized companies?  They have a lot more to lose if a one-man vendor goes south on them.

Case in point:  Back in 199-something, when I was a team leader at former employer, I led my dev team through a custom dev project for one of my old employer’s clients.  In 2003 I got word that the client had parted ways with my old employer and was looking to have some custom modules built to bolt on to the product I had built for them way back when.  Figuring I was a lock for the job, I called my old contact at the client company to get some specifics and prepare a bid.

To my dismay, I was told that they were unwilling to accept bids from “one-man show.”  They indicated concerns about support, about availability, about the possibility of my being hired away, about their ability to get the level of service they were used to from larger vendors.  Not once did they express concerns about my ability to do the actual work (I asked).  But in all these things, they were right.  Never mind the fact that the revenue from that project would have allowed me to staff up and turn down any other projects for a good year or so, dedicating all my time to this client.  Never mind the fact that they were pleased as punch with my previous work.  The bottom line was, one guy working from his house – no matter how competent – was simply not the type of business they felt comfortable dropping large amounts of money on to entrust with a critical business system.

The kicker is that the company they ended up going with was comprised of a whole 5 people – that’s not exactly a big shop.  But those 5 people had a real office with a real T1 line, they had a decent corporate image, and they could afford to dedicate one staffer full-time to this project from the get-go.  I could have dedicated myself full time to the project, too, and I had all the necessary expertise, but I was not (in the client’s eyes), a “real” business – I was just some guy who writes software.  I can’t help but wonder how it would have played out if I had invested some time in a corporate image that “faked the plural” and gave the impression that I was part of a larger team.  At the very least, I would have been allowed to bid.

Of course, this was a very big client company.  None of my small business clients care that I’m a one-man operation so long as I take good care of their project, and I do.  But if a guy hopes to grow his business and work on projects of a non-trivial nature, is it not in his best interest to project an image slightly larger than life in order to attract business that might otherwise not notice him?  I’m not talking about deception here – if you can’t perform the work and meet the expectations, then you shouldn’t pursue the business – but if you have everything the client needs except the image, is it not wise to polish up your image as well, even if that means making your operation look larger than it is?

I mentioned above that I’m planning to launch a micro-ISV myself.  As a rule, I have never referred to my current consulting practice as “we”; it has always been clear that I am a one-man operation.  But at the same time, I can’t say I have any real philosophical objection to one-man companies who use the term “we” in their marketing communications.  And I won’t say for certain that I’ll never use the term “we” self-referentially once I’m in the products business and start trying to make sales to larger companies.  Knowing me, I probably won’t.  But if it gets in the way of winning business that I know I can deliver on, I will re-think that stance – no question.

Professionalism Means Saying “No” Sometimes

Sometimes, to get the job done, you have to say “no.”

That’s exactly what Microsoft developers did with regard to the schedule for Longhorn, the next generation of the Windows operating system.  The product’s feature set was recently cut back in order to bring it to market on time.  This is good news for PC vendors, who were afraid that PC sales would lag badly as people waited for the next version of the OS, but it is even better news for software developers everywhere, because it sets a very good precedent.

All too often, non-technical managers will demand that a development team deliver feature set X on date Y, with no regard for whether or not such an accomplishment is feasible (this kind of boondoggle usually happens when a company falls into Pitfall #1 – a salesman or executive, eager to make a sale, told a client that they can have feature set X on Y date without consulting anyone from development first…but I digress).  And the unfortunate part is that most software developers, being somewhat beta, will put their heads down and work endless hours of overtime until the feature set is implemented, albeit poorly.  And to make it even crazier, most managers are so pleased that they met the date that they don’t really care about the poor quality of the software.  I recall that at one job I had a number of years ago, the manager told me “just get it minimally working by the delivery date – that way, anything that doesn’t work can be paid for under User Acceptance Testing – but if it’s not delivered by that date, we have to eat those fixes rather than bill for them.”  This is sounds nuts, but it is not at all unusual in the software industry.

Thankfully, we have a big fat precedent being set by Redmond right now.  The Longhorn team vetoed the feature set for the release date.  No manager will browbeat them into promising to deliver a bloated feature set by 2006.  Nobody will threaten their jobs.  Nobody will demand that they work crazy amounts of overtime to get it done.  The professional software engineers have spoken, and their employer listened.  Bill Gates said:

The Wins team, in terms of its progress and performance, is doing very, very good work, but it couldn’t take the additional features and make an ’06 schedule. That’s professional engineering on its part, to stand up and say, “No, if you want us to have those features, we’re an ’07 deliverable.”

Now that, my friends, is encouraging.  Here we have the most prominent manager of software developers in the world telling his team “you know what?  You guys are professionals – you know what you’re doing.  If you say there are more features than you can deliver by ’06, fine – we’ll cut features to make the ’06 ship date.”  This is going to make it tough for managers to tell their teams “no, you have to implement ALL these features by X date – and if you can’t do it, I’ll get someone else who can.”

Thankfully, I don’t have this kind of problem with my clients – when they ask for certain functionality by a certain date, I come back with what I can do by that date.  More often than not, they trust me.  We work together to figure out how much of what they need can be delivered by that date.  Nobody threatens me.  Nobody calls my abilities into question.  Nobody tries to bully me (actually, a few have tried, but they cease to be clients right then and there).  Perhaps this trust is extended to me only because being a consultant carries more cachet than being “just” an employee, but I’d prefer to think it’s because I have a good track record.  Unfortunately, my good fortune is the exact opposite of what I see happening in the trenches of software development, where developers are browbeat into working to unrealistic deadlines all the time.  Before I was in business for myself, I saw it – and lived it – all the time.  For example, I was once given three weeks to cobble together an entire product from half-working modules and libraries!  The reason?  Some salesman sold a product that didn’t exist, and promised delivery by months end, all without consulting a single technical staffer to see if it was feasible.  The project was a wreck and the client eventually fired us – but hey, at least we made our first ship date!

So if Bill himself says that this is the way to handle a conflict between a delivery date and a feature set, what possible excuse can any manager have for refusing to cut features or slip the date when a similar conflict arises on one of his projects?  None that I can see.

Managers – trust your developers.  You hired them because you believe they can get the job done (and if you don’t believe that, then you need to take a serious look at your company’s hiring practices).  These people are professionals who know what it takes to build good software.  When they tell you that a thing can or cannot be done on a certain schedule, don’t ignore them.  A good software project must be coaxed, never forced; to do otherwise is to ensure low quality and an abundance of re-work.

The 5 Laws of Choosing a Software Developer

This one is for all the businesses that need to hire out for some software development work but don’t have the necessary experience to reliably choose a winner.

So you have a software project in mind, and you are trying to choose the right developer to take on your project and bring it to life.  But how can you avoid hiring a rank amateur who merely talks a good game, or a pure programmer who understands how to write code, but doesn’t understand your business?  After all, it’s easy to claim to be a software developer; no licensing is required, and there are no public records of who has done good work or bad work for you to look up.  All one needs is a computer and some books, and a “programmer” is born.  This low barrier to entry makes life difficult for both the clients and the competent developers.  Luckily, you can save yourself a lot of trouble by demanding these 5 items of any software developer you hire.

1) Demand Experience.  Unlike the stock market, past performance is a great indicator of future results when it comes to evaluating a developer.  Certifications and degrees are good, but they only tell part of the story; it’s better to look for your prospective software developer to have at least 5 years of experience in positions of ever-increasing responsibility.  For most small business projects, you need someone who has done more than just write code; the ideal candidate will have experience successfully leading entire projects from start to finish.  A person who has worked as a programmer can write code, but an actual developer is a notch above that.  A developer someone who can analyze your business needs, design the project, write the code, implement the project and provide support afterward.

2) Demand References.  Ask your developer candidate for a list of references, and be sure to contact them.  In addition to asking about technical competency, ask questions about the developer’s approach to customer service – is the developer available by phone or eMail a reasonable amount of the time?  What kind of a response does the developer give when asked for emergency or non-emergency help?  Along with the references, you should ask to see samples of work the developer has produced that is similar to your project.  If the developer asks you to sign a non-disclosure agreement before showing you these samples, that is reasonable.

3) Demand Value.  You should never select the least expensive developer you can find; that virtually guarantees that you are hiring an amateur, and will get your project in trouble.  Instead, look for the best value – the place where price and results meet.  An exceptional developer might outperform a mediocre one by 10 to 1 in some cases, but cost only 1.5 or 2 times more; that means your total project cost could potentially be much lower than if you hire a less-skilled developer who lets your project get out of control.  Some developers will request that you pay a deposit at the outset of the project – this is reasonable, and is a common business practice.

4) Demand Communication Skills.  If you show me a person of average intellect with exceptional communication skills, I will show you a person who can be trained to be a better software developer than most of the introverted geniuses you hear about in this industry.  The best developers out there have taken the time to learn how to speak your language (the language of business) and will happily listen to your comments, opinions and concerns, then explain to you in plain English how their proposed solution is going to work, and how it is going to help you.  If you find you are unable to communicate effectively with each other, it’s best to move on to the next candidate.

5) Demand Availability.  Nobody expects a software developer to have only one client or project at a time; it’s just not realistic.  At the same time, you need to avoid hiring a candidate who is hopelessly over-committed.  The first thing to consider is: when can the developer schedule your project to begin and end?  What is the developer’s current workload?  What kind of a schedule can you expect your project to progress on?  How often can you expect milestones to be completed?  If you have a hard deadline, discuss it with your candidate; make sure the developer can commit to meeting it.

Repeat After Me: I Am Not In The Software Business.

As I work in this industry on a daily basis, I come into contact with more and more people who write software in one fashion or another.  Some are hobbyists, some are small business owners trying to be more productive, and some are professionals who get paid to write code and develop software.  I am always surprised at the number of professionals who, by word or deed, express that they are not concerned with business problems, only with technology problems.  I’ve worked with people who will gladly stay up all night long trying to figure out why IIS isn’t delegating security credentials from one machine to another, but are absolutely uninterested in figuring out whether or why the business needs a web application in the first place.  I am an artiste, this particular subset of software professionals seems to say.

If you’ve ever encountered one of these types, you know it.  And although these folks are in the minority within our industry, they are visible enough to give us all a bad rap – one bad apple and all that.  So for the benefit of everyone who creates software in one way or another, let me say this:

You are not an artiste. You are not even in the software business. You are in the problem-solving business. More to the point, you are in the business-problem-solving business. The technology problems you solve should always be in the context of solving a business problem. If the solution to a particular business problem offers less benefit than the effort required to solve it, you should be working to solve a different problem.

There, I said it.  A lot of people will not like hearing this.  Some will disagree vehemently.  And that is OK.  But the truth remains – it is the job of the software developer to solve problems.  Technology does not exist in a vacuum.  A well-written, elegant, extensible, scalable, n-tier application has no intrinsic value.  It is only when such an application solves a business problem that it creates value.  That’s why we call them applications – unless the software is doing something, it’s just bits and bytes on a disk someplace.  As a profession, we need to get hip to being able to recognize and understand business problems.

In fact, sometimes technology is not the solution to a given problem at all.  Just the other day a client asked me to re-write a portion of the home-grown application he uses to run his business.  I declined, pointing out that a simple change in process in his back office would solve the problem they were having.  A pure technologist would see this as a technology problem, when in fact it was a very simple business problem.  Now, I could have re-written that module and made a decent amount of money doing it.  And sure, that would have solved his business problem just as well as the process change would have.  But there was no need for that particular expenditure of time and money to be made.

It is important to avoid the old “when all you have is a hammer everything looks like a nail” type of thinking.  And personally, I think a lot of us need to be reminded of this fact.  Admittedly, my point of view is colored by the fact that I didn’t study computer science in college – I studied management.  But the most successful developers I’ve met are the ones who, regardless of training, are able to understand that technology supports the business need, not the other way around.

Now, lest anyone think I’m belittling programmers or software developers, I am not – remember, I make my living in this industry, too. I stated earlier that I am talking about a relatively small but visible subset of the profession.  As developers and programmers, we possess specialized skills that are frequently vital to the effective operations of businesses big and small, just like the specialized skills possessed by accountants, craftsmen, managers, and salesmen.  It is all part of the great mosaic that makes up a business.  I believe we matter in the workplace, and we matter a lot – so long as we remember why we matter.  We matter because we solve business problems.  Those of us who are content to flip bits and bytes with no desire to understand “why” in a business sense, or with no desire to make the bits and bytes line up with business value, are at the very least wasting the valuable material between their ears.

To have a desire to code – and only code – for a living is OK.  But to wear blinders while doing said coding for a living is not – that effectively reduces you to the role of an assembly line worker who adds his piece to widget as it rolls by on the conveyor belt, never to see or understand the completed product.  And I think that good coders and good developers are much, much more valuable than that and have much, much more to offer.

To those who shy away from business issues, I say:  come out of your shell.  Nobody is asking you to be a business analyst, but at the very least, always seek out the business context of what you are working on.  Always.  At the very least, always seek to be better informed and truly understand why you are building what you are building.  Always.  It is better for your clients.  It is better for your career.  It is better for the image of the profession.  And it is better for the economy at large.

You Can Never Be Too Thin…Or Too Rich?

The war between the thin client and rich client rages on. According to a recent item on CNN, IBM intends to push the thin client to new heights with its Workplace product. We all know the stated advantages of served-based computing and thin clients – ease of deployment, lesser support cost, greater portability, and so on. These are good things to have, certainly. IBM is probably being realistic about this product, realizing that Workplace alone is not going to break the Windows stranglehold on the corporate desktop. Personally, I continue to maintain that the desktop is never going away. After all, power and ownership are still big factors with people when it comes to computing – hard drives and memory are way too cheap to NOT make good use of. A terminal hooked up to a server is only going to be able to do so much.

That said, I welcome the new old thing. I’m sure that the swinging pendulum will continue to move toward terminals for a few years, then desktops for a few, back and forth until someone comes up with a truly new paradigm for computing at work or at home. In the meantime, there’s more than enough diversity in the world of computing for both thin and rich clients.