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.