While there are several positive aspects that can come from this approach, there are several problems that can easily be created that stem from the problem that in most cases the rest of the company really isn’t a customer in the classical sense. Why? Because they lack a true buying choice. Furthermore, it generally isn’t in a company’s overall best interest for their divisions to really be customers of their own organization.

The original motivation for taking these approach is usually to address several issues:

• Division buy-in on costs and priorities: If they are directly paying the bill, they are going to pay for what they want and not ask you for things they aren’t willing to pay for.
• Clear status and communication: The project reporting and communication model is simpler for everyone to get their head around if it’s based on something we’ve very familiar with. Each player can figure out their part.

If you model the relationship between the IT organization and the rest of the company as a service provider – customer relationship, it’s easy to miss the transitive qualities of this: if they are your customer, you are their vendor. The word Vendor casts things in a different light: If you’re a sufficiently large organization you probably have a vendor management office whose sole job is to ensure you pay the least you can for things and fosters competition between vendors. Their job is largely to keep the company from getting too cozy with any one vendor. Are you ready to be just another vendor, like the one that bids annually to supply fresh coffee or office supplies?

Benefits

There are several good things that this model will tend to create.

• Defensible functional requirements: Unreasonable requirements tend to be expensive relative to their value, and the division is more ready to discard them.
• Role Clarity: The Vendor/Customer relationship is relatively easy to understand, and each party can generally determine their role quickly. When there are disputes, there’s a natural framework for resolution.

Challenge One: Buying Choice

It isn’t a long road from treating your internal divisions as customers until they look at you as a vendor. Once they consider you just another vendor (like the one they selected to provide fresh coffee to the office, or office supplies) they’ll want the advantages that come along with being a customer. For example, it’ll seem clear to them that it should be optional to use your services. This will feel very reasonable to upper management – it’s all part of the transitive nature of IT being accountable.  If IT can’t deliver a service at the best price, why not go to another provider?

This will likely start with something that will be difficult to argue against – such as a large software development project, perhaps in a language that your in-house talent isn’t familiar with.  Now, what about hosting for that product?  If you are charging back true costs for your data center to each division, you are unlikely competitively priced with what a division could get from Rackspace or Peer1.  It isn’t necessarily that those companies are more efficient than you are at doing the same thing (indeed, if they are then you should broker your own contract with them) but instead that it isn’t an apples-to-apples comparison.

Challenge Two: Implied Requirements

Whenever an internal IT organization takes on a project, there are a number of implied requirements that affect cost and schedule. Some of these requirements are from the IT organization itself (like technology choices) and others are from the corporation (role of internal staff and contractors, project management and reporting standards, etc.). When a division looks to bid out work to an external source, these requirements are usually unstated because in many cases they aren’t requirements the division has on the solution.

Another way to look at it is that any constraint on the solution that the customer (the division in this case) doesn’t have or care about is an implied requirement and likely a competitive disadvantage when comparing internal IT costs with external costs. In broad strokes, the difference in requirements is that a division’s requirements are almost entirely about outcomes, not methods: They care about the results their users get, not how they are achieved. IT organizations often focus their requirements on how results are achieved (using this technology, in that enterprise architecture, developed with our RUP-based approved process, tracked by our PMO) and they defer to the division the functional requirements.

Local Maxima and Minima

When each division or cost center is free to chose what services they are willing to pay for, they will converge over time on only those services that are good for them. Establishing shared services is generally challenging because each party will want to ensure that everyone is paying their fair share. This is often tricky to define – should it be proportioned by feature usage? Capacity?  This often creates a “first mover disadvantage” scenario where no part of the company wants to be the first to get a new service such as a database server or SharePoint Portal because they’ll be hit with the entire cost of it unless someone else comes along.

Secondarily, upgrading services gets challenging because no drop of rain believes it is responsible for the flood: If you want to upgrade to Exchange 2007 from Exchange 2003, one division can easily say that they don’t believe it’s necessary and thus decline the costs. If you need a larger server to house SharePoint, who is going to get the bill? A game of chicken often gets created where multiple parties all want a service, but no one wants to be the first to ask and risk subsidizing everyone else.

With each cost center pushing to only pay for those things it perceives sufficient direct value to take on, they are making decisions only based on what gives them the best cost or maximum value. This isn’t likely to align with providing the overall lowest costs for the company. For example, three separate departments could easily decide to implement their own direct attach storage for disk because none of them feels they can justify the cost of a SAN, however together it would be less expensive to construct and maintain a central SAN environment with SAN backup.

There are some straightforward exceptions to this problem where shared services are generally easy to get consensus on and cost out. Typically these are raw infrastructure services such as email or file storage where there are clear units of measure that allow for proportional billing (mailboxes and gigabytes used, for example).

An Alternative: Clients, not Customers

If the Customer/Vendor model isn’t the overall best approach for a company, what alternative model can provide the benefits without the unintended consequences? How about a term that’s between User (which has accumulated a substantially negative connotation) and Customer – Client. A quick trip to the dictionary shows that a client is any person or group that is the party for which professional services are rendered, which fits reasonably enough.

As your clients, they still are entitled to a great deal, just like customers would be. As the client of the project, they:

• Determine success & failure: Your project isn’t successful just because it follows the corporate processes or works on the corporate approved IT infrastructure; those are the constraints on how you solve problems that are immaterial to your client. Success is determined by whether you achieved the goals the client created. That may mean you need to do some extra communication to make sure your client knows that their goals were met, even if that’s not in the standard process.
• Decide if it’s worth the price: In the end, the problem may just not be worth solving.  Many things can be done but the cost in time and distraction exceeds the value.

Unlike a customer, since you’re part of the same organization you can share with the client your insight into the costs and risks of the project in a way that no vendor ever could.  In the end this creates the best partnership that delivers long lasting results.

A final note

If you don’t treat your users as clients, odds are very good they will eventually get themselves a buying choice. When they do, they won’t chose you. Don’t let it come to that, it isn’t ultimately in their interest, your interest, or your company’s interest.

If all this sounds a little off kilter from reality, perhaps a few hard numbers would help:

Quoting Computer World, who asked “Do Business Desktop PCs have a future?”:

While desktop PCs account for the bulk of personal computers sold to enterprises, the gap in laptop sales to enterprises is closing. Of 168 million PCs sold worldwide to professional organizations in 2008, about 95 million were desktops and 73 million were laptops. That’s compared to 94.6 million desktops and 47.3 million laptops that shipped in 2006.

Now, as with any statistics there’s two ways to look at these numbers:

1. Laptops have grown tremendously in their total percentage of the market, and that growth rate has them on track to take over the world.
2. The majority of the growth in computer sales is coming in the form of laptops.

The gazelles are taking the first road.  And why not?  People love to assume the disruptive is true, it’s a lot more interesting.  Before you charge down that road, consider what seems likely.  There are a few problems with the first conclusion:

• Two data points don’t make a pattern: If you follow the trend back farther, the sales of PC desktops has held up consistently, but laptop sales go up and down.  This would seem to indicate that the most likely interpretations of the data are that either the overall market is expanding (for example by people having two systems) or that this is a momentary, periodic surge in laptop purchases.
• Past large growth rarely projects forward: Just because there was a large growth in one year (either in absolute or percentage turns) doesn’t mean it will repeat at all.  It’s just as likely that the next year pattern will be flat or even retreat.

So before you see the first twitch and assume it signals a migration of the whole herd, step back and think through the underlying facts.  Is this really the first sign of a monumental shift?  Or just another twitch of the needle?  Then look at your own situation.

Now, we have a few laptops, but we have more hard core desktops – the laptops are used for on the road presentations or working at Starbucks for fun.  Of course, we’re developers so we’re in the category of users that are always excluded from the norm.  But what’s not to love about a desktop?  For the same money they will always be faster and more capable than a laptop because they don’t have the burden of being small or extra power efficient.  Even if you buy into the idea that everything will be run through the web so computers are just glorified terminals…  Something still has to compose all of those web pages and make it all come together, and web apps can burn a surprising amount of processor and RAM locally.

In the end, I think we’re seeing a lot of folks buying second computers or getting additional laptops for other uses that complement their primary work computer experience.  Additionally, there are folks in emerging markets that need what laptops offer (self-contained, reliable power) more than performance but this reflects an increase in the overall market, not a shift in the existing market.

• If you take a piece of wood and don’t sand the surface smooth it won’t take a stain evenly.
• If you let glue creep out of the joint and get on the wood, the stain won’t look right in that spot.
• A piece of dust on the surface will get magnified by each layer of varnish.

Each layer depends on what’s underneath it.  Any flaw in a lower layer will tend to get magnified and distorted by layers above it.

Whenever I get involved in enterprise architecture I get reminded of this analogy because I often run into irrational exuberance that you can add a layer to an existing system and paint over the flaws underneath.  I was involved in a few projects like that early in my career:  It was too hard to talk directly to the mainframe from the web server so you put a layer in front of that.  There was already a C++ layer doing a DCE RPC gateway, but that was also too hard to program against for large use so we added a COM interface to the DCE RPC gateway.  We made some prototypes and validated the concepts and charged in full bore, only to run into big delays and teething problems near the end of the project trying to get everything polished up and suitable for production.

The problem is that at each turn you may be making the developer’s short term life easier by giving them an interface more natural to their preferred programming environment but since it just builds on the layers underneath it will end up with all of the limitations they have – and they can show up in the most surprising places.  For example, we ran into problems where certain input would cause failures which we ultimately discovered was caused by % being used as an insertion marker in a gateway library several layers underneath what we were doing – so at best it would drop the % and the following character, but at worst you’d get back a random data element if you managed to create a valid insertion name.

Layering issues are particularly problematic because they tend to be data sensitive and highly situational depending on how the various layers interact.  This means that it’s very difficult to design a comprehensive test plan:  The system can act as if it’s nondeterministic, making it infeasible to state with certainty that the various modes of the software have been demonstrated by a test plan.  At best, you can say that it worked for the exact test inputs it was given.  When you do have a problem in production, the multiple technologies in multiple layers can make it particularly hard to debug because it requires a lot of chairs around the table to hit all of the possible players.

Are you decorating?  Or covering up the problem?

Whenever you’re part of a team proposing adding a new layer over an existing system to fix its problems or adapt it to a new situation, you should be suspicious.  Is this really the right path to make the API look right?  Or are you temporarily covering over a problem?  If it’s the latter, it’ll just show through later – and now you have two problems to deal with not one.

There are good occasions to add a new layer:

• To smooth technology upgrades: When you are shifting technologies, say from COM to .NET, you may want to create a custom layer as a new standardized interoperability adapter which will let you separate the upgrade problem into phases and handle them independently.
• To support multiple technologies: Sometimes you need to support multiple types of clients – varying either by environment (say Java and .NET) or major architecture (say Client/Server and Web sites).

And a few suspect ones:

• Mitigate architecture risk: To isolate a new subsystem architecture from the main codebase. We’ve heard this one before – you want to try out something new and iffy, like say Entity Framework.  To contain the risk, you want to introduce a layer between it and the rest of the platform so if it all goes bad you can easily swap it out.
• Impedance Mismatch: You need to interact with something, but just don’t like the way it works. Perhaps it throws around ADO.NET recordsets and you prefer to work with strongly typed objects.

If you find yourself in one of the suspect scenarios, you should seriously question whether the work you’d do to create and validate a layer is really forward progress or just yak shaving.  Before you go down the path, you should seriously estimate:

• Fixing the underlying problems: If the underlying layer(s) aren’t doing what you need, what would it take to get them changed (in the technology they’re currently in) so you could work without adding another layer? That puts the responsibility where it belongs, and keeps complexity under control. Do a full estimate of this approach.
• Make a parallel layer: If you ignore the powerful aversion to creating duplicate routes to the same data, what if you created an alternate path to the underlying information. It may be that you bypass all of the layers or just some of the layers (such as down to the stored procedures that call the database). While this creates duplication, it lets each platform work in their own optimal way and allows for deterministic testing.
• Using the existing layer as it is: It’s easy to overstate the impact of reusing a known system with issues. There’s a natural tendency to not realize that you’re comparing a well understood but flawed system with an unknown solution with unknown problems. Trading known problems for unknown problems makes everyone happy at the start of a project, but creates significant project risk downstream.

Put down the shovel and back away

When you create a new layer on top of existing layers you are often digging your project into trouble, both now and downstream.  In addition to problems with each layer creating a leaky abstraction, deploying and supporting these highly layered systems is extraordinarily challenging.  It becomes prohibitively expensive to make changes in lower layers because of the high chance of unexpected side effects showing up as defects in dependent applications.  More often than not, each layer has to be held static with any changes accommodated by creating new queries or items at each layer to be served in parallel with the older methods.

Before you go ahead, be sure you look at the total lifecycle cost of that decision, including support and maintenance.   Have a good or bad experience with putting up some software wallpaper?  Let us know in the comments!

Seriously people

First, Apple makes some of the finest hardware you can possibly buy.  If you compare it nose to nose with hardware that’s actually built to the same standards then it really doesn’t represent a significant price premium.  Compare a Macintosh Pro with an equivalent Dell workstation – the cost is within 5%.  It’s amazing that Apple can afford the extra engineering of an OS with that little premium.  

Second, Vista works great.   It’s running on many more systems than Mac OS is, and with volume comes a range of new problems.  The total amount of money I’ve spent on desktop antivirus software in 10 years of administering PCs?  $0.  The total number of virus problems I’ve had? 0.  My parents managed to get into trouble with one virus and Windows XP – but installing the (free) Microsoft Defender cleared it right up never to return.

As with nearly all marketing, this is a battle of perception:  Apple has done a great job of defending their brand at every turn.  This is part of their corporate ethos.  Along with a few other tenants it ensures they are a much loved but niche player:

• Only do something you can do uniquely well.
• Don’t extend into markets that might ask you to compromise your values.
• Cultivate the mystique:  Don’t show what’s behind the curtains.

Microsoft on the other hand has tenants that ensure they’ll be a volume player, but an unloved one:

• Play to win the most market share in any market you can.
• Build your ecosystem by making it easy for others to add value to it.
• Cultivate the engineers:  Provide overwhelming amounts of documentation and approaches.

The fact is, many people don’t need a top end piece of hardware like a Mac.  On the other hand, many people want a computer that’s just a tool, not a piece of art.  To them, the nearly infinite diversity and low cost of entry are essential.

I’m a People person.  I’m Good with People!

The computing needs of the average corporation and the average individual are very far apart.  To companies, computers are tools – like the desk, phone, and copier.  Very important, very powerful – tools.  They aren’t there to make you feel great or enable you to create a cool video of your vacation in France.  My partner really summed it up one day when he commented that the Mac was a really personal computer - it worked hard to create a personal connection.  

Corporations on the other hand want slow paced evolution, massive support for legacy applications and hardware (these guys are still running dot matrix printers off parallel ports) and to control costs.  They also philosophically want to have all the keys to the computers – just like they do for the buildings and offices they own.  PC’s are just end points on the large mesh that is the corporate IT network.  It’s very impersonal.

Microsoft makes a great deal of money providing businesses with the tools they need to have the computers work for them, and Apple makes a great deal of money creating computers that people love.  Either of these goals would be compromised by trying to do both.

Vista Goggles

Folks that have been in the Windows ecosystem a long time probably recognize that you could take the first year of press about Vista and substitute “Windows 2000″ and find the same article written 8 years earlier.  Vista is a surprisingly large and tricky step forwards on a number of fronts, whereas Windows XP was a visual redress of Windows 2000.  

Almost like an SAT test:

Windows 7 is to Windows Vista as

Windows XP is to Windows 2000.  

Like Windows XP, the story on Windows 7 is making virtually no architecture changes and instead just tuning for the long haul.  That’s a great thing, because there’s a lot that works very well with Vista, and now it’ll work even better with Windows 7.

The humorous thing is to read now about how people are thinking about moving to Vista once 7 ships because, well, they don’t want to move to an OS that was just released.  It’s as if Vista has been aging like a fine cheese on the shelf so the very same binary code that once was toxic is now just what the doctor ordered.  To a slight degree this is true:  Vista SP1 did address some issues that affected some people, and more importantly hardware now is dramatically faster than it was two years ago (as it will be two years from now…) so what once was aggressive is now commonplace.  The same was true of Windows 2000 when it shipped.  Requiring 64MB of RAM?  That’s just crazy talk!  Only certain video cards worked reasonably with it, and video drivers to a while to stabilize.  That sounds very familiar…

In the end, it really comes back to Perception.  Probably the biggest mistake Microsoft did was not push the OEM’s that make the computers to build machines that could responsibly run the new operating system, and be clear that meant hardware 3D video cards and plenty of memory.  And oh yeah, stop putting aftermarket firewalls, antivirus, Google Desktop, and all kinds of other things on them that are ill optimized.  At my last company we got in the habit of routinely wiping each new Dell that came in and reinstalling the OS from the Dell restore CD – because that got rid of all the noise.  It was surprising how much better that worked.  Is that Microsoft’s fault?  Not directly, but they certainly could have found a way to encourage the ecosystem to forgo some profit for usability.  But that’s just not in their corporate DNA.

With any luck, the big story for Windows 7 will be that Microsoft pushes back against their channel, even being willing to risk it by leaving Windows XP out there for folks that don’t want to play by the Windows 7 rules.  It’s hard to put up barriers when you’re a legal monopoly, so find ways to use incentives to do it right instead of punishment for doing it wrong.  And keep up the ads, because perception does matter in the long run.

Who knows, it may push Apple to get better too.  Just once when my iPod updates itself to enhance stability and performance I’d love to know what exactly was unstable or slow…

The prevailing wisdom appears to be:

• Google is the world’s best technology company.  Anything they solve they are the best at, and if you aren’t doing it their way you’re a dinosaur.
• Client / Server is dead.  All new applications will be web applications, most likely delivered as a service.

We visit a lot of companies, both prospects and clients.  Here’s what we’ve actually seen over the past two years:

• Outside of search, Google doesn’t have their act together.  Pretty much everything else is an academic experiment.  There’s nothing wrong with experiments, but there’s a big distance from there to running your business.
• Business are run on Client / Server.  They’re still creating new apps this way – they may use newer technologies like WPF to do it, but if it is core to making the business work, it’s usually not a web app.

With a name like Google, it’s got to be good!

Our own internal experience mirrors this.  We use Exchange and Outlook for email so I can’t say a lot directly about Gmail, however it’s clear from Google’s reactions to recent outages that their perspective doesn’t fit the enterprise because it doesn’t take into account the premium companies place on predictability and communication.  Predictability meaning that things are consistent – you get a consistent experience so your users can get their jobs done.  Businesses are change averse for good reason:  Users will adapt even to crazy problems and discover the patterns that work to get their jobs done.  When the patterns keep changing, they get frustrated.  On the communication front, businesses prize feedback on knowing the true scope of a problem and how long it may take to get it resolved.  

SalesForce learned this a few years ago and in response introduced Trust.Salesforce.Com, which went a long way to getting companies what they wanted to be comfortable with an outsourced critical solution.   If you operate a SaaS, you would do well to model after this.   Now, it isn’t necessarily bad that Google doesn’t do anything like this for Gmail – it just means it isn’t a solution for a large set of businesses.  

The thing we use the most internally from Google is Google Analytics.  It’s very pretty and easy to use, however we’ve noticed a lot of “what’s broken today?” experiences with it, enough that we can’t recommend it to anyone.  Two of the sites we monitor appear to be chronically under counted by Google Analytics, and we can’t figure out why.  And like most things Google – you’re on self support.  Now, there are paid options however unlike email we haven’t been able to find a strong paid competitor that is actively competing with Google.  It feels like most have left the field of battle, or are exorbitantly expensive (and aimed at large enterprises).

After much early on talk about how Google Docs was going to make Office obsolete, it simply hasn’t come to pass – and Microsoft continues to sell a lot of copies of Office.  It turns out that making a great word processor and spreadsheet is a very hard problem to do through the web.  Now, you might take the perspective that Microsoft’s announcement that they are going to offer lightweight web versions of Office 14 applications as being an admission that the old model is bankrupt, but it really points to an increase in reach:  Reaching many users that wouldn’t have been purchasing the product before.  Casual home users that wouldn’t purchase a “real” copy of office may find what they want in Google Docs, and would also be happy with a lightweight feature set of Office.

In Google’s defense, the products are worth what you’re paying for them:  Free.  But, you have to ask yourself:  If it wasn’t for the Google brand, would you give them the time of day?  For search, absolutely.  Finding an address and getting a street view?  Bring it on.  But don’t feel bad for depending on traditional software next time you want to buy a copy of Office, Photoshop, or use Outlook for your email.

It’s all SaaS These Days

Make no mistake, web applications, SaaS and Cloud Computing are all here to stay.  However, that doesn’t mean that there isn’t a lot going on in Client \ Server as well.  The key question to consider is how many applications you would have made, but done in another technology are being built as a web app instead?  There certainly are some, but for the most part web applications are creating entirely new spaces and solving problems that weren’t being solved before instead of replacing entrenched problems.  

Take document management:  On the surface this feels like a problem that should go entirely web and not look back because the web is very good when the readers to editors ratio is very high.  That said, the big document management companies still have very robust, integrated traditional offerings as well as their web portals.  You do have people using web document management solutions (like SharePoint) that never had document management before, which is a case of expanding the size of the market not replacing an alternative option.

When you are running your business, you have a set of requirements that are often best suited by a traditional client application:

• Users need advanced capabilities:  Once you stray out of the basics, it is invariably harder to provide features through web technologies than traditional technologies.  Tools are improving and making it better, but the cost per feature is lower in a modern client development environment than through a browser.  This is particularly true since you can put a browser in your app to enable things that it does really well – like show HTML content – you just let it do and keep the tricky stuff – like that big set of coordinated data entry fields – in your traditional app.
• Users are doing a lot:  One thing that is easy to lose perspective on is that when you run a client/server application every computer is bringing power to the party.  You often don’t need that strong a central server because the real action is happening out on the clients, and every new client that logs in is bringing their own muscle with them.  In the web, it’s all on the server. Not only that, but you’re rendering things in a less efficient way due to the stateless nature and limited protocols available for data exchange.
• Users need access to diverse data:  With web technologies it’s straightforward to manage information once you’ve brought it into the cloud, but it’s tricky to provide end users with fast casual access to a range of data in a range of formats.  In many businesses data is coming in pieces from many sources and being assembled to produce a coherent output.  This isn’t easy to do in any environment, and it’s one thing that the modern PC operating system, particularly Windows, has gotten very good at.  You can double click a file and almost always get it to open into a good viewer.  You can preview files, drag and drop from one program into another or a file into a program.  All of this is intuitive and fast for users that aren’t fitting into a pre-packaged user scenario.  

There are counter balancing effects:

• Transient user community:  The more far flung your people are, the more work it is to keep them up to date.  The more transient that user community is, the higher a barrier installation is.  This is the leading reason why you want to make something a web app:  It just isn’t worth the deployment effort to do it any other way.
• Diverse user community:  If you want to service Linux, Windows, and the Mac then web technologies are the lowest common denominator, it’s just the way it is.

What we’re seeing in the field fits into this:  People are creating a lot of new, lightweight web apps to solve point problems they probably wouldn’t have solved through technology before.  But they’re also still heavily investing in traditional applications.  

As a development team, it’s easy to get caught up thinking that Effort is the same as Value – just because something was a lot of work it must have a commensurate value.  The fact is, that there’s just no evidence that effort and value are correlated.  On the web, if you want to create a great looking and functioning generalized tool you’re signing up for a lot of effort.  And the value may be there – it could be that you’re going to reach a whole set of new users that otherwise wouldn’t use an application at all.  On the other hand, it could be that users perceive no extra value for it being in the web so all the extra work you put into creating the graphics, testing in five browsers, establishing identity, and the dozen other things you wouldn’t have needed to worry about if you were just running on the desktop netted you nothing.

So if you’re a business wondering how to approach that next application you need, don’t be afraid to get one that isn’t all wrapped up in Web 2.0 goodness.  In the end, it’s all about making the solution work for you and your users.

While the projects were successful, it bothered me that the secret sauce seemed to be a rigid adherence to schedule and delivery more than any other consideration.  This was exactly the reverse of how I wanted projects to succeed:  I wanted them to succeed because I was treating the developers how they always wanted to be, not like a stereotype from Office Space.  How could it be that better results came from ignorance of the technical details involved?

Developers Will Use All Available Time

Upon reflection, the first thing that struck me was how much an immobile deadline focused discussions and decision making. If you give a team more time, they will expand their process to consume it.  Time will get consumed by:

• Elaborate Decision Making: When you have little time, you make a choice and go with it until it appears it just can’t work.  When you have a lot of time, you sit back and look for the very best option.  That then requires defining what the best is – is it fastest, or smallest, or most scalable, or whatever.
• Development Approach: Under pressure you’ll tend to go with the proven guaranteed approach.  If you have the luxury of time you’re more likely to engage in yak shaving like investigating a new tool or approach, or writing several prototypes first before you develop the real solution.  You might even just throw caution to the wind by skipping a formal design figuring you’ll have the time to just code and test your way to a solution.

The more time a development team has, the harder it is to argue against spending it on up front luxuries.  It also can be harder to argue for long term best practices because the team has the time now to develop a solution any way they want.

Unknowns Create Boomerang Estimates

Even very experienced developers are generally terrible at estimating the duration of developing a solution.  This has been demonstrated over and over by many other parties.  The key behavior that we’ve observed is the phenomenon that from when you approach a specific development problem (like displaying a graph on a web page) until you know exactly how you’re going to solve it (and have a reason for confidence in that approach) you will tend to estimate high because in effect the only reasonable estimate is infinity.

Put another way, as long as you don’t know how you will solve a problem you don’t know for sure that it is solvable which means it will take an infinite amount of time to solve it.  Fortunately, developers are almost universally optimists so they believe they can solve anything eventually – so they’ll pull out a standard answer like three weeks or months or whatever feels like a big chunk of time to figure out the problem but not so big that it kills the project.   The reality is that until you know how you’re going to solve it, it feels like it could take forever.

Once a solution has presented itself  the development team will often find that all it will take is some cleanup and polish to be done- a very small amount of time.  What will push the team to find the answer?  We’re back to the problem of elaborate decision making when you have the luxury of time.  Finding solutions tends to not be a linear problem that will be solved with incremental development energy.  Instead, it tends to be solved by getting people together and brainstorming possible solutions until you find a few candidates and can work out what it’ll take to prove them out.  Under pressure, people tend to focus their creative energy and be more willing to compromise.   That flexibility will tend to get rid of pet requirements and developer gold-plating and focus on the most critical aspects of the problem.

What’s the alternate approach?

The key is to not let your knowledge and experience as a developer lead you to buy into the stories the team creates around what’s reasonable to get done and how long it will take.  Instead, you have to stick with the project’s goals first then the facts of the project.  The project’s goals form the objective reality of what has to be accomplished for the project to survive:  Deliver this functionality by that date, keep these people informed, solve these problems without causing those problems.

When the team runs into a wall and needs more time, instead of buying into the story of needing a lot of time, set a specific and tight goal that keeps a solid amount of time pressure on the team to solve the issue and prevent the problems above from showing up.  Ideally, find a way to give out one or two day chunks to answer incremental questions if necessary to emphasize that time is precious and has to be invested carefully.  This is where you can leverage your experience in a way that a non-developer can’t:  The team knows they can’t snow you with tech details, and you can define a specific, measurable result that can be achieved in a short period of time that they can’t argue with.  Despite this, you are bound to have to assert a few times that the time limit is the limit – solve the problem in that time.  It’s very hard because you’ve been on the other side of that conversation and it can feel like you’re the Pointy Haired Boss, but it’s fundamentally your job on the project.

What will nearly always happen is the team will surprise itself – a solution will be presented within the team that they can live with and can be done in the time they have.  It may be incomplete or have some risky shortcomings, and you’ll want to ask how long it’d take to address those.  You probably shouldn’t address them in the first round, but the team will feel better that you’ve considered through things and will buy into the outcome more if you ask.  You’ll also want to make a record of it so that the team can in the future recognize what was a predicted shortcoming vs. an accidental defect.

Do you want it solved right?

This is a question that often gets voiced within a team as a rebuttal to external time pressures and is very dangerous.  The challenge is that most non-technical people don’t get the number of ways that a problem can be solved: instead, each problem appears to have a single solution.  Take away your technical knowledge and imagine you’re the paying customer:  What’s the alternative – were you going to solve it wrong? If that’s the case, what else have you done that’s garbage?  If you took your car to a repair person and they said it’d be $500 to fix it, then when you came back they said well, if you want it fixed right it’ll actually be $1200, wouldn’t you wonder what the hell the $500 fix was?

Usually this statement is uttered in desperation when a team believes they just need more time to figure out a problem.  Nobody wants a problem solved wrong.  Skip the hyperbole and get down to action:  break down the problem into small chunks of time that can be invested for a specific measurable result, and make sure the team gets that overage time is the most precious commodity.

Side Note: This is an advantage of SCRUM in practice.  If you’re following an Agile Development practice, particularly SCRUM, this fits right in:  Focus on making each sprint deliver the user stories it was supposed to even if you have to leave some special cases for a later sprint.  The daily stand up meetings are a great place for the different team members to apply team pressure against over engineering and doomsday estimates.

Cleaning Up and Closing Out

At some point you need to close out your release and ship it. For each of the areas where you’ve had to make compromises and taken shortcuts you have to choose to either:

• Ship as Final: Decide the implementation is close enough to the intent of the end-user functional requirements that it can be the final implementation (at least until new information contradicts this decision)
• Ship as Temporary: Decide that something is better than nothing and ship the feature with limitations.
• Cut the Feature: Hold back the feature until it can be reconsidered or reimplemented.

You’re nearly always better off shipping the feature, often as a final feature pending more information because it’s very hard to gauge the true impact of each limitation.  This is particularly true of user-facing features and environments where it’s possible to evolve the software rapidly.  Inevitably once it’s in the hands of your users you’ll discover aspects of it that you didn’t think of that will require rework and you may discover that the killer feature you were sure would be the hit of the release is hardly used.  In either of these cases if you’ve invested a great deal of time in making it foolproof the team will tend to resist changing it.  It’s a natural product of the presumed relationship between effort and value.  If necessary, you might put in some temporary safeties to detect and catch the limitations you’re worried about.

The major exceptions to this approach are areas that are too dangerous to deploy if less than fully trustworthy.  For example, if your team is developing a data storage system, software deployment system, or other critical infrastructure your choices likely resolve down to making it as right as possible or holding the feature until it can be reworked.

If it turns out that the solutions that are viable within the schedule have significant limitations, you should make sure these caveats are known to the business – provided you can express them in business terms.  For example, knowing that an algorithm won’t work if your userbase doubles is probably not a significant caveat, unless you know the business plans to double in a relatively short period of time.  Every system has limits, and every software change has risks.  Business representatives don’t like to hear the same items covering the same ground repeated every time you discuss software, and it tends to make them not hear the new and important information as well as sound like you’re attempting to transfer accountability from your team to them.

Now step back for a minute and look at it from the employee’s perspective.  When someone needs access to IT resources within your company, there are really three interests you have:

1. Access: People need equipment, software, accounts, and access to IT support.  This is the basic block & tackling that you are handling now.
2. Effective: The tools you provide need to deliver on the business needs the user has.  Whatever’s in the way of that – defective equipment, user training, or suitability to task needs to be addressed.  The best computer with the right software in the hands of a user that doesn’t know how to use them is worthless.
3. Security: Access to your network means access to all of the data and work products within it.  You need people to understand how you approach security, what they are and aren’t allowed to do, and how you’re going to work with them to maintain security.

Setting the Stage

Employees often develop a personal and possessive feeling about the equipment provided to them by a company.  They think of it has their computer, just like they have a computer at home.  This creates a range of problems for your organization by extension:  If it’s their computer then when there’s a problem they’ll want their computer fixed, not a different computer that’s suitable.   They’ll come to regard problems personally, not objectively.

Instead, you want users to look at the equipment they’re provided to do their jobs as just that – tools that enable them to be more effective.  Stepping back into the big picture, a computer isn’t any different than a wrench or a filing cabinet.  It isn’t their computer or phone, it’s the company’s – designed to make them effective at producing whatever the company needs.   When your user community gets this, they’ll self censor their support requirements:  Watching a DVD movie on the company laptop won’t feel support-worthy.

The best time to establish this is to set the right expectations up front:  Have this conversation before the user gets their network account.  The goal is to make sure they understand that:

• You’re committed to their success.  You’re passionate about making sure they’re effective.  You have a support system designed to make sure that their issues get resolved quickly, and you have provisions for support off hours and when they’re on the road.  If they aren’t sure if you can or should help with an item, you want them to engage you anyway – You’ll let them know.
• The technology is there to make them effective at their job. Your job (IT) is to make sure that they are as effective as possible at that.
• They are responsible for their effectiveness. If they need something – training, repair, whatever – it’s their responsibility to get it, and they can get it.
• They are responsible for their user account. Anything anyone does with that account is their responsibility.   That means if someone figures out their password, or they leave their computer unlocked, or otherwise treat their user account with less than the respect it deserves then they are going to be held responsible by the company for that.

Support Your Local Sheriff!

It’s painful to hear on Monday that a user was trying to get something important done and couldn’t due to a simple issue you could have resolved.  Perhaps they knew they could have contacted you for support – but didn’t for whatever reason.  What users will remember is that they had a problem, and it kept them from getting things done.  All of the work you do to support users – special on call staff, phone numbers, email contact, whatever – didn’t work because they never got called upon.

To address this, you want to address as many of the human factors that keep people from calling on support as you can.

1. Make sure you’re always available: The cost of setting up a toll-free number for users to contact support is trivial.  If you don’t already have an on-call rotation, set one up and make sure there’s someone to answer that toll-free number at all times.  The same person can answer an email address designed for support.
2. Make sure they know all the ways: In the past, we’ve published business cards with the 800# for support and email address, and we put these cards everywhere:  In laptop bags, in a card holder at the front desk, anywhere that we could think of so that there’d be one around when a user needed to know how to contact support.
3. Talk to users about it: Be cheery.  Make sure they know that you personally are driven to make sure they’re successful, and you look at it as an honor to help them out after hours.  They need to really get that you want that phone call, because you need to conquer the very human desire not to bother or inconvenience other people.

We really recommend making up a business card that has all of the key information a user needs – the contact information for support, company fax number and main phone number, remote dial in for voice mail, common URLs for external access to email and other services, pretty much anything they need to know on the road.  I’m sure you have it all committed to memory, but if you’re an employee that doesn’t travel every day you probably don’t.  Little steps like this can dramatically affect the general user population’s opinion about IT.

Security Begins at Home

You want to make sure that each user gets how seriously your organization takes security.   People often don’t treat their user account with the same respect they’d treat a physical key or card.  Most users wouldn’t give a stranger the keys to their office or building but would give their password out over the phone to someone who claimed they need it.

People worry a lot about security threats from the Internet, but most break-ins – overwhelmingly – happen from inside.  Most of these are done either through social engineering (where the intruder convinces someone to give them access) or by a disgruntled employee.

To address these common threats, you need to address the key social aspects of security.  In addition to normal sensible security practices,  we recommend establishing a few policies:

1. IT Personnel NEVER ask for passwords: Make it clear to your IT Support organization and every user that no one in IT will ever ask them for their user ID or password.  Therefore, if anyone calls you asking for that information you know one thing – they aren’t authorized to it.  If they give their password to IT, or IT hears that they gave it to someone else, their password will be reset.
2. No one will use their account but them: If IT needs to do something logged in as you, they’ll do it in your presence – after all, you are still accountable for what happens with your account.

The second one may cause some heartburn with your desktop support staff- they’re probably used to solving a range of user problems by accessing the computer as the user, and anything that’ll get in the way of that is a problem.  While it may cause some inconvenience – you aren’t going to be able to do work that requires logging in as the user if they aren’t around – the message this sends to your users about how serious you are about security is essential.  You need to be cleaner about the rules than they are.

What about Non-Employees?

What should you do with contractors or others that need access to your network, even temporarily?  If they are getting a user account, they should go through the same procedure.  You have the same goals:  You want them to be effective and not compromise your environment.

Finally, Ditch the Input Devices

Most computers come with mice and keyboards that are dirt cheap.  If this is what you’re using and you’re recycling a computer, please – get a new mouse and keyboard.  Most computer companies do the same thing when they process returns.  The fact is that keyboards get filthy quickly, and while I may not mind the crumbs from my pop tarts, it certainly isn’t going to create the right impression if I get one that’s full of someone else’s.  You should be able to score new ones for your HP, Dell, or whatever for not more than $40 and really – with what employees cost in salary and other expenses, don’t you want them to know you care?

Have a story about how you support your new users?  Share it in the comments below or drop us a line to tell us about it.

In the past several months the three partners of our firm have been scattered to handle all of the challenges of our growing business, but with the completion of a major engagement with a client we had the opportunity to spend some time back together to focus on more long range concerns.  We had intended to spend the time working on product and marketing strategy for our upcoming commercial release of Gibraltar, but instead on a whim decided to do something we called the Code Monkey Challenge.

The goal was to make something complete and useful within a very short period of time.  Complete for us meant we were going to create a software component, test it, package it, and publish it to a new web site with descriptive content all in 48 hours.  We didn’t even have a hosting company set up beforehand.  To be useful it had to be usable by people outside of our company as delivered, and fulfill a real need, at least for a set of users.

We started at 9:00 AM with the goal of publishing the final version to a new web site by 6:00 PM the following day.  Our initial approach was to have one hour sprints of work divided between each team member, then meet and review and set up the next sprint.  In the end we used three hour sprints, delivering to each other through our source code system at the end of each sprint.  We made our goal – you can see the results at www.gibraltarsoftware.com.  Most importantly, we achieved our result of bringing together our team members.

Update:  The small Logger we wrote as part of the Code Monkey Challenge has since been rewritten and incorporated into the Gibraltar Agent.

We eliminated any distraction we could so that we could apply as much of the 48 hours as possible to the project.  We worked well into the evenings and had others provide some support to make sure we had food, coffee, and no outside distractions.

The intense time pressure gave us a good tool to eliminate most conflict: there simply wasn’t time for much philosophy on how to approach the different technical aspects.  The lack of time removed ambiguity that otherwise would be the source of conflict.  There wasn’t much time for yak shaving either – we had to produce results at the end of each sprint.  Still the first few sprints were spent mostly in exploration and validation of the approaches with our first rough cut of each element done by the end of the first day.  The second day was then about refining and documenting.

While we did skip over some aspects that we would normally do on a larger scale project, we did include most elements of our preferred development process.  We did coordinated sprints of the team separated by an after action review to adjust our plan.  We distributed code and results between the team through our source code control system, we wrote automated unit tests to verify key aspects of the system, and did peer design reviews.  If anything, the lack of time made us less likely to bypass most parts of the process because we knew we wouldn’t have time to dig our way out of any problems we created.

The real goal of the exercise was to bring us back together as a leadership team and establish more of the shared experiences that define interpersonal relationships.  It’s helpful to bridge the gaps that easily develop between architects and developers, developers and designers, engineering and marketing.  We all had to come together to achieve our result because it was clear that we’d all fail if we couldn’t.  Most business projects are sufficiently fuzzy that it isn’t nearly as clear what the cost of not working together is, and politics can overwhelm cooperation.  It’s an experience I’d recommend in any software team, particularly if you’re in a company that can mix skills and responsibilities.

The next time your shop is done with a project, or when you need a break consider doing your own Code Monkey Challenge.  It only takes two days.  Here’s the rules:

• Produce a Real Product: Scope out a product that is really useful to a specific audience.  Sure, you’re giving it away for free, but it still needs to stand up to scrutiny.
• Marketing Material Too: What good is a product if no one knows about it or understand how or why to use it?  Even though you’re giving it away you want people to be able to understand and take advantage of your effort.
• Help and Usage Information: Like a real product, it has to be usable without you sitting over the customer’s shoulders.  Depending on what it is, you need to tell them how to install it, program with it, and provide guidance on recommended usage scenarios.
• In Little Time: Extra time is the enemy – it will reduce the pressure to work together and encourage unnecessary bells and whistles while removing the catalyst that gets everyone to work together.
• Publish to the World: If you’re  a large company, perhaps it’s just the company.  Wherever it is, it has to feel like real stakes to the team:  Your results will be on display.

To set it up, be sure that you can eliminate anything that would distract the team – they can work into the evenings, have food brought in, whatever.  The closer it is to a total immersion experience the better.  It improves the sense of camerarderie developed within the team and ensures the most creative energy is directed to the project. 

If you try it out, or have another software team building story, please drop me a line and tell me how it went, or leave a comment below.

This is fine as far as it goes, but like any metaphor while it may be a way of explaining some aspects where two things are in common it’s very easy to overextend because in fact it isn’t a true financial liability.

Take a hypothetical example: You are supposed to add federated identity to your web application. What you want to do is create an identity broker that will allow your SaaS application to connect with Microsoft’s ADFS, OpenID, and a few variations of SAML. You believe this will get you the market reach you need, and by creating your own identity broker you can decouple your application from changes in this still evolving space, as well as support your own native security technique.

As you dig into it, you realize that this just isn’t feasible in the time you have: You need to get a solution done in two months to meet a commitment to a customer, and it turns out this customer just uses ADFS. It just so happens that your web framework can easily work with ADFS directly, so to save the schedule you drop back and just do ADFS. From a development standpoint this is a hack – you are doing something quickly you can’t extend to meet the original requirement and you’re pretty sure that you’ll need to undo this later and do it right, which will cost more than just doing it right the first time. This is Technology Debt.

Metaphors have Limited Application

The metaphor doesn’t hold for long.  First, unlike real debt there is no external requirement to pay this back.  Perhaps you never will need to support more than ADFS, or that after all of the talk customers just won’t adopt federated identity.  At the start of each release cycle, you can look at the competitive market and see what is the correct, most important work to be done.  It might be that you’ll have to make good on something you deferred, but you might not.  If you didn’t, it never was debt.  How confident are you that you can tell the difference right now?

Second, all technology has future liability. The more code you write, the more you have to maintain and support. That has a cost as well for the future. Depending on the nature of your product it could mean that you have to support questionable past API decisions or obscure and intricate features of your product. Every feature has a cost to maintain, every line of code you use or reference in a third party library has weight. Only talking about deferred development as technology debt implies that what you have right now is all asset, but it isn’t.

Rampant Misuse

The biggest challenge I’ve seen is that the metaphor is used to push development team goals on the business without having to adequately justify them.  By handing business folks something they can easily relate to, it’s easy to gloss over the underlying technical implications.

For example, say you have an application that’s currently written in Visual Basic 6.  You can justly claim that Microsoft has dropped support for it and that the day is coming when it will no longer run on the latest operating system (Microsoft has committed that it will run on Vista and Windows Server 2008, but that will likely be the end). This sounds very alarming indeed!  Naturally, the answer is to rewrite the entire application in .NET 3.5. Yes, this will take longer and cost a lot more than just adding the features you need to the existing code, but it eliminates all of the technology debt represented by that old nasty VB6 code.

Now look at it a little more objectively. Yes, you will need to eliminate that VB6 code at some point – notably when you are upgrading from Vista to whatever’s next.  When will that be?  Well, if you believe the hype that people love Windows XP and may just consider Vista in the future, you have some calendar time. As long as it’s done by then, Microsoft dropping support isn’t a real issue.  We’ve yet to work with a client who’s VB6 application didn’t work just fine on Vista, thank you very much.

Second, with rare exception every modern technology has a half-life. The notable exceptions are COBOL, C, and C++.  You can with confidence know that these languages are still going to be in active use in 15 years and that code you create now will work with minor to modest adjustment on current platforms at that time.  I would dispute if a similar claim can be made for the latest crop of languages.  A major reason for this is that modern languages are really whole environments – a programming language and an API/runtime.  While it may be theoretically possible to write a C# compiler without toting along the .NET runtime, it isn’t going to happen.  Likewise for PHP, RoR, and even Java.  Java’s framework is much more shallow which ironically will likely give it more life because it can adapt to radical changes in computing environments and there is already an intent to decouple most of the code from specific frameworks.

This means that today’s latest and greatest environment will be tomorrows VB6.  Just listen to people that jumped on .NET 1.1 discuss how they’re going to upgrade to .NET 2.0 or later, and that’s really not a particularly dramatic move.

Fundamentally, when you purchase software you’re making a bet in the vendor and community behind it. This is one place where the LAMP stack has a number of advantages because of the openness of the environment and the institutionalized tolerance of actively supporting releases for a long time. This is fundamentally enabled by their open source nature, but even if you had the source code for a commercial product it’s not likely you could do much with it; unless it’s fairly simple the burden of maintenance is likely higher than the cost of replacing it. Counteracting this are a lot of hidden costs to open source that may be difficult for a small team to absorb.

Easy Metaphors Seldom Produce Great Outcomes

Next time you’re trying to bridge the gap from technology to business, try to stay away from simple metaphors like Technology Debt. Instead, have real conversations to articulate the potential business impacts of the technical decisions and then hear from the business what they are concerned about. With a real dialog, everyone is in on why you deferred work to later and what bet is being made, and no one will be surprised when you do show up in a year to start porting that VB6 app to .NET.

Nearly all teams work within a relatively closed ecosystem – the technologies and people represent only a minor subset of all technologies available today.  Even within these small groups the number of choices at every level are daunting.  Even if you’ve selected your OS, language, framework, and database – what architecture model are you going to use?  What is your data access and caching strategy?  At each turn you’ll want to pick the best option but have a flood of choices to select from.  Many people can tell you about how they led a project that used any particular technology and it worked like a champ with no drawbacks.  On the surface it makes it possible to defend just about any new technology as the way to get your next project done.

What is very hard to find is a real comparative analysis that highlights in comparable situations the results with different technologies.  It’s not a surprise this is so – such analysis is very expensive and time consuming, and few companies would try to solve the same exact problem using competing technologies because it’s not the business they’re in.

Where does this leave you?  What technology should you use on the next project?  Most likely, you’ll have the best success with an incremental improvement on the technologies you already have in your toolkit.  Why?

Infinite Solutions in Infinite Diversity

Most conversations in technology on the web are exclusive - they advocate X over Y or Y over X.  The truth is much more that X or Y can both solve the problem but do it in different ways and with different levels of effort for a team starting from scratch.  What’s much more useful is to ask why you can’t solve the problem effectively with the tools and technologies that are a natural fit for your environment.  Even if a new technology may be the easiest way to solve the specific problem you’re looking at it may not be the best choice when you consider everything that goes into creating the entire software system and maintaining it over time.

When confronted with a strong advocate for a technology shift, keep the conversation focused on the benefits of shifting away from the natural or familiar selections for your organization.

New Methods are Expensive

When you introduce new technologies or tools there is always a short term hit.  Most respected research indicates that even technologies and tools that have a substantial improvement in effectiveness are at best neutral on the first project that uses them.  The most successful technologies and tools are ones that are evolutions of things your team already knows.  The more divergent it is from that, the more time it will take to get over the learning curve, establish best practices, and generally become effective.

Known Problems vs. Unknown Problems

A common challenge when comparing a new technology against existing methods is not recognizing that while you know of all of the problems with your existing technologies, you don’t know of the problems with the new ones.  This can lead to a comparison that shows a number of critical problems with the current technology, and none on the new technology.  It isn’t that there aren’t problems with the new technology, it’s that you don’t know what they are yet. Whenever you put in a new technology, no matter how promising it is, it is going to have new, unexpected problems.

What’s worse is that your organization most likely has workarounds for every problem you’ve encountered, so they don’t really have the impact of a new problem.  Your development team may not know about them, but talk to the operations staff, support staff, and your users before you assume that a technology problem that worries you really is at the top of their list.  It may be that the big memory leak in a third-party library that has you wanting to rewrite a subsystem is conquered in production by having a script reset the service every night.

Existing Code and Libraries

It’s very easy to underestimate the value of existing libraries and practices in effectively solving problems.  When faced with a new assignment, your developers can draw from a large pool of existing, tested solutions to a range of the more mundane, plumbing aspects of the solution.  This includes storing user information, reliably working with data storage, security systems, and other functional requirements that aren’t unique to the problem at hand.  These software libraries accrue over time as developers face similar problems even in development shops that don’t place a high emphasis on modularity and reusability – as long as you have source code control and developers that aren’t paid by the line of code, they’ll naturally find ways to adapt and remold things they’ve already done to fit new needs.

When you have a major technology shift, losing the use of this common body of code will require the first project to reinvent it.  On the surface this may seem straightforward but it’s usually held up by a desire to understand exactly how to best accomplish the same common tasks in the new environment.  For example, you might have written your own security system for your previous environment which you’ll then need to either re-implement or drop in favor of a built-in capability of the new environment you’re targeting.  What’s worse is you need to make these critical decisions at the time when you have the least experience with the new environment:  Is its built in security system really sufficient for your needs?  What about logging?

Your Customers Don’t Care

With the exception of a narrow range of situations (such as developer tools), your customers really don’t care what technology you use to implement your solution.  After all, they’re buying your solution not the technology you wrote it in.  Even if the IT representative of the evaluation team in a potential customer objects because your entire solution is written in a technology they don’t like, in the end they are often overruled unless they can point to a practical implication that you can’t mitigate.  For example, you may get overruled because it’s a Unix shop and they won’t accept a solution that only runs on Windows.  Even in the most extreme cases, if you provide enough customer value it will conquer any customer technology objection.  If the prospect has no Windows servers, that translates into a finite cost for them to support a unique system in their environment.  If your value well exceeds that, then it isn’t the key challenge to crossing the chasm to that prospect.

We often hear developers discussing internals of software development and giving them the weight of user requirements.  If it isn’t visible to the customer, it isn’t a requirement. In the end, your customers don’t pay you to have a beautiful object model.  They don’t care how hard it is for you to create your product or what hoops you have to run through.  For them, it’s a cash for capabilities decision.  It may be true that doggedly sticking with an old technology will mean you can deliver fewer features with each release, or you won’t be able to run on the latest operating system but in the eyes of your customers the question is still how compelling the functionality is and whether you can run on the operating systems they use.

Ignore the Pundits

If you’re part of a shop that has a track record of producing results, be proud.  Don’t worry about what is all the rage at producing the next social networking site, focus on what is effective for you.  For projects that can afford the risk, take the opportunity to incrementally improve your technologies and methods:  Try out a new version of the development framework or new capabilities of the latest database version.  Just remember, you can always tell the pioneers:  They’re the ones lying on the ground with the arrows sticking out of their backs.  Unless you’re part of a dedicated research team, most often you’ll get the best results by waiting for the first round of adopters to figure out what did and didn’t pan out with the newest release and then benefit from that experience.  There’s no satisfaction in burning six months working out the kinks of version 1.0 just to have everything addressed in version 1.1 published a month later.

What’s Your Experience?

Have a great story about being the pioneer, working a project that was packed to the gills with the latest and greatest, only to fall on its face?  Or perhaps you found raging success completly severing your ties with the past?  Drop me a line or leave a comment about it.