Are We There Yet?

"So when will you be done with this development project?"

I don't know about you, but I hate this question. There simply is no good answer for it. It seems like such a simple question with a simple DateTime valued answer. One of these days I swear I'll answer with, "Oh, I'll be done next Tuesday at 2:34pm." just to see what happens.

And seriously, businesses hate that we have such difficulty answering the question. It seems perfectly reasonable for them to want to know when they can plan to have the new processes that they know they desperately need. Developers demand high salaries and are ostensibly professionals, they should be able to give a professional answer, right?

The Road is Well Paved

The thing is, software development is a lot harder than people expect it to be--and this includes software professionals. Even simple software projects can run afoul of hidden complexities that can destroy well meaning estimates and make everyone unhappy. And no matter how you hedge your answers, people simply don't remember all your caveats, maybes, and what ifs that you use to indicate uncertainty.

The end result is that developers seldom make their ship-by dates and companies become disillusioned and impatient with all software development. That's not helpful for anybody, but it's pretty much the rule anymore.

And the fact of the matter is that the vast majority of developers (and development managers) never learn how to answer the estimate question. They'll move from company to company, repeating the cycle of hope, suspicion, and disappointment over and over again. Which works well enough for the developers in the boom times when the demand for development is so high that mildly talented house plants can get hired as developers.

So a lot of people are making the same mistakes over and over. Businesses can be excused for assuming that this is simply the way things are and feel confident in their distrust of software professionals. They've been there, done that, bought the t-shirt.

Paying the Toll

This environment causes developers who care about these kinds of things a lot of heartburn. Everyone pays for the ongoing cycle of disillusionment. I believe that this is what really prompts posts like the recent ones from Ted Neward talking about professional ethics. And I've been known to throw my own hat into the ring as well.

We get tired of paying for the sins of those who have gone before. And I'm not referring to the messed up legacy code we stumble into, either. Frankly, messed up code is the least of your problems coming into a situation with a client who has been burned by previous developer promises. Companies that have had deadline after deadline missed have a degree of mistrust that is very hard to overcome.

We pay for this distrust in a hundred different ways. The thing is, trust is a paying commodity in business. Working with partners you trust means a whole lot of overhead you can simply skip. An analogy: if I trust a plumber to fix my sink quickly and professionally, I can go get a burger and leave him to it. It's only when I don't have that trust that I have to pay the additional overhead of having someone I do trust watching to make sure he's not napping under the sink.

Want to see a business manager go into a dreamy fantasy? Ask them what it'd be like to be able to trust their software developers (in house or not). The more experience they've had with developers the more intense the fantasy.

The Rubber Meets the Road

We have a couple of areas of friction in businesses that exacerbate this situation. The main disconnect with business managers is that we have borrowed terminology and tools from other disciplines without understanding that our processes are fundamentally different. It's tricky because the temptation to use manufacturing terminology is immense. After all, we are creating a product of sorts. This makes so much sense on an intuitive level that it's hard to realize that the comparison is misleading and potentially dangerous.

I wish we could retrain everyone to make analogies to other business specialties. Scientific research or law come to mind as potentially useful analogies because both are similarly plagued by the impact of unique situations, changing ground rules, and unforeseen complexities. It would be interesting to investigate how managing software development like a patent application or drug research would change how we look at the problems involved. We might have stumbled onto iterative cycles and responding to altered requirements a whole lot sooner, for example.

Paying Attention

The real problem, though, is that most developers (and even most development managers) don't take the time to learn about common friction points. Nor do they take the time to build relations with their business counterparts so that you have some political capital (aka trust) to use when it is needed. It's easy to forget that much of the progress in software development practices are pretty recent in terms of business processes. After all, business managers don't move at the speed of light and changes tend to take time to penetrate those layers.

Which means that a whole lot of industry advances aren't even theory yet in the board room.

And the fact of the matter is that you cannot expect a business manager to understand what makes Agile practices work. Or the reason that strong unit testing saves time over the long run even though it takes more time up front. Learning to communicate at a level that is sufficiently detailed for smart business decisions without getting bogged down into the jargon inherent in any specialty is an invaluable skill, and one best learned earlier than later. That means thoroughly understanding those theories yourself--not just on the surface or in buzzword compliance. It also means learning to communicate that understanding from orbit, 30,000 ft, 5,000 ft, and right on the ground. This is hard to do. It takes practice. It also takes exposure to business manager types. I'm not sure which is harder...

Something to think about, though: not learning this skill leaves you at the mercy of those who do learn it.

My point, though, is that it takes both. You have to learn your profession so thoroughly that you can deconstruct its "best practices" ("design patterns", whatever) and rebuild them from basic principles on the fly. AND you have to learn to communicate that understanding comfortably to people of varying familiarity with software development in a business environment.

That's what it takes to be a true professional. It's easy to let those two skills fall out of balance. Individuals who understand both are invaluable to a company. Also rare. Companies who discover someone capable of both are often surprised at how much smoother things run with that person placed where they can do the most good--a point Jeff Atwood's latest on becoming a better programmer drives home.

So I don't have a formula for quick and accurate estimates. Just a lot of hard work. Still, here's a tip for free: anyone asking for a firm delivery date is inherently assuming BDUF. Once you know that, you know where to start your answer.

29. January 2007 18:19 by Jacob | Comments (4) | Permalink

Caveat Renter

Renter beware. I've heard a number of technology companies lately extol the great virtues of renting—both hardware and software. They sell the concept to their investors and shareholders and talk about the wonderful revenue stream they will build. And I'm afraid that is all that they see. As such, they are doomed to failure. There will be a backlash, mark my words. The thing is, as pointed out in Infoworld,

But we don't see any vendor propaganda promising that we'll save money by renting.

In fact, companies moving to rental are missing a fundamental rule of business—the customer is king. The whole point of capitalism is that the absence of compulsion means that you have to win customer dollars by providing something people want. And the bottom line here is that nobody wants to rent. At the very most fundamental, nobody wants to rent unless doing so is significantly cheaper than buying. Not just a little cheaper, significantly cheaper. Renting means that someone else has control over your destiny. It means you do not own the tools that make your business run. In something like IT spending for businesses in particular, where change represents significant cost, you do not want to be dependent on another company for the continuing good function of your computer systems. It is suicide. And Ed Foster at the same magazine says similar things about "maintenance" contracts which is rent on the back side.

Companies aren't going to agree to draconian rental policies just because tech companies want them to. Even when they want them to really badly and they prattle on about bug fixes and free upgrades.

  • Fact, free upgrades won't happen—companies will invent new names and split upgrade paths to, well, generate more revenues.
  • Fact, bug fixes aren't going to happen any faster with rental agreements—you can guarantee that companies won't bump spending on support and programming just because they have more revenues coming in.
  • Fact, new revenues will go to new programs, new initiatives, and new products to generate new revenues.

Consumers are not stupid. Companies who see their customers as walking revenue streams have lost the focus that made them successful in the first place. You build revenues by accurately identifying the wants and needs of your customers—not by accurately identifying their budgets. My advice? Avoid tech companies with great plans for rental revenues like the plague—not only their products, but I'd stay away from their stock, too. The resentment of their customers will rebound and they will end up the worse for it.

Technorati Tags: ,,
13. June 2002 10:34 by Jacob | Comments (0) | Permalink

Sun Blind

Attack! One of the fundamental rules of business I have learned is that to succeed, you must attack the leader. If your efforts aren't geared to become better than the current #1, then you don't really have any justification for existence. Find the weaknesses, become more efficient, discover hidden customer wants.

Attacking yourself is a problem with Sun Microsystems. They just don't seem able to do it. Oh, they do okay when they’re in the pack somewhere competing for profits, but whenever they find themselves ahead, they have a tendency to sit back and enjoy the scenery. But even worse is when Sun only thinks that they’re number 1. Their release of Java as a competitive development language was brilliant and they managed to put it out there with enough oomph to attract every anti-Microsoft developer on the planet. And they achieved enough momentum and enthusiasm that they thought that they would be able to coast into number 1 position in development languages. Coasting along for the last year, they haven’t been very responsive to the development community. They’ve delayed standards reviews. They’ve stalled on effective IDE issues. And, perhaps worst of all, they stopped pushing Java in broad marketing initiatives.

The result is disaster. Java is steadily losing ground to Microsoft’s .NET and there’s no end to the slippage in sight. By not maintaining their momentum, Sun has allowed Microsoft to overcome their advantages and leverage the millions of existing Microsoft developers into the Internet development arena. As a result, Sun faces more than just the direct challenge of VBScript vs. JavaScript (or even VB.NET vs. Java). Now they face whole architectures they let get out of the bag with what amounts to no answer from Sun—XML, ADO and SOAP to name the most obvious, and groundbreaking, examples.

So have they learned from their mistakes? Unfortunately, the answer seems to be “no”. Scott McNealy seems to have decided that his ego alone can overcome any obstacle and he has failed to give any answers with substance about how Sun will manage to overcome these threats to Java. This is making a lot of developers who have banked on the popularity and utility of Java very nervous. New third-party tools are coming out that help extend the usefulness of Java immensely, but these tools can be expensive and make a poor comparison for a development house that is looking at the ease of VB.NET and comparing that to the hoary, expensive, patch-work monster that Java has become.

Good thing Sun has that lovely server business to fall back on. Um, or maybe not. While Sun was playing around doing whatever they were doing back there, their server market is being eaten alive from the bottom. Sure, Sun makes incredibly reliable servers, but they’re pricey suckers and Sun hasn’t implemented any substantive improvements recently. In other words, they didn’t attack themselves. Their prices didn’t come down until they started losing business and that is far, far too late. Further, consumers have found that if reliable costs too much, they can often achieve the same results with less reliable, but redundant. Thank Michael Dell for that little epiphany. Dell pushed server prices so low that you can afford three of his servers for the price of one Sun. And that’s after a major price-slash on the part of Sun.

My prediction? Sun is in for a tough time. They’re clearly in decline and the pit seems to be bottomless. McNealy and co. don’t seem to have fully realized their danger. Upon hearing that Sun needs to recalibrate, Scott McNealy’s response is simply “We couldn’t be better positioned.” He’s known as a tough guy, but even tough guys get knocked out if they’re not careful. Particularly when they walk around with their eyes closed.

What do you do once you're #1? Same thing. Attacking yourself is a tough thing for companies to do and it isn’t something they typically do well. Those who do, however, will tend to reach number 1 and stay there. This principle is the single biggest factor in the continuing success of Microsoft. Bill Gates is the most paranoid man on Earth and he is convinced that if he rests on his laurels for even a moment, some upstart will come around and nail him. He’s right.

Technorati Tags: ,,
15. May 2002 10:29 by Jacob | Comments (0) | Permalink


<<  February 2017  >>

View posts in large calendar