One of the biggest criticisms that NeXT (now Apple) has faced with object-oriented technology is that objects are hard to understand from a business point of view. What do inheritance, polymorphism, dynamic run-time, selectors, and so on have to do with the bottom line? More importantly:

Why should businesses get on with the NeXT order of business?

The biggest problem facing programmers who love the development environments and tools behind Apple's OPENSTEP and WebObjects is that management is always stuck in a Microsoft way of thinking. "Let's get this whole network wired with NT and put Visual C++ on every programmer's machine - we'll definitely create great apps since we have the best tools by the best software company." There's just one problem:

It isn't true.

More on that later. First, a little history is in order. Back when NeXT still existed, in its last days before being sold to Apple, they had a pamphlet they would send out to anyone interested in OPENSTEP ENTERPRISE (NeXT's version of OPENSTEP that ran on top of Windows NT). Here's the lead paragraph:

"The NeXT development environment includes sets of pre-assembled, compiled objects that provide common application functionality. You focus solely on building core business logic - saving time and money. The key to this savings is reusing logic across your enterprise that is either pre-built by NeXT or built by you."

What the heck does that mean? And what does it mean to the bottom line? By the time any regular manager finishes reading the first sentence, he's ready to say frostily, "We'll be in touch." NOT! Quick tip to marketing copy writers: anything that leads to confusion also leads to lost sales. Please remember that.

Let's focus on the four words that any manager can appreciate - "saving time and money" - and we'll use a really awesome piece of Apple's technology, the Interface Builder (IB), to illustrate how true it is.

Let's say that you are a project manager who is very well placed at a Fortune 1000 multinational company. The executive committee of XYZ Corp. has decided to introduce a new product line that their marketing research had identified as the Next Big Thing. XYZ's CEO, COO, CFO, CIO, and CxO have decided that they want to be first to market in both Europe and the Americas with this kind of product. However, they also know that they have no way of knowing how to properly forecast demand for this product. That's how it is for new products that are the Next Big Thing - nobody has any idea how well the product will do. So the CEO of the company has decided that they are going to manufacture this product on a build-to-order (BTO) basis here in the States and in Europe. Guess whom they've chosen to receive the assignment of building the software to control this process:

You.

You hear the Mission: Impossible theme beginning to play...

Your mission, should you choose to accept it, is to create a very large-scale custom app that will be deployed throughout your organization. This app will not only be used for the sales force to process orders, it will also be used for:

1. Supplies procurement. When the CEO says supply procurement, it's going to need to know exactly when to order more supplies for manufacturing and yet at the same time not build a huge inventory of supply parts. In procurement, it's got to be able to automatically initiate and process supply orders to XYZ's suppliers when raw materials get to a low enough level, and yet dynamically scale the orders up to levels that the app projects (imagine giving an app some good AI logic when it comes to procurement and supply modeling).

2. Manufacturing process tracking. It's going to have a lot of UI. That UI is going to be used a lot and will be pounded on by more than just your testers. It will be beaten to death daily by thousands of other people in your organization. There will be no part of XYZ that will not have this app on their systems. Everyone, from the CEO on down to the entry-level guy on the line, will be working with this app. The guys in manufacturing who will actually assemble the product will be using it to register any problems, and the CEO will be using it to track the progress of the product's sales and manufacturing.

I don't know if you've figured it out yet, but if it were me, I'd think this was a make-or-break, bet-the-company app. If this app goes down, the company's future could go down with it. The CIO of your company has given this job to you as his way of saying, "If you can do this, you will have my job in 24 months." The CEO has said to you, "Do this properly and you will report directly to me." One of those so-called mission-critical custom apps has just been handed to you.

What do you do? Having never heard of OPENSTEP or the Interface Builder or EOF, you know that you're going to have to hire and deploy a small army of programmers to get this job done. You've got to tie your labyrinthine Oracle 8 database with this puppy in order to make your intranet worth all that money you've just given to Netscape. This is the project that will get you written up by the Gartner Group, Dataquest, and every other consulting firm that looks at your company. Arthur Andersen is already calling you up every single day to ask you how many consultants to send to you while you put this together. Booz-Allen, Hamilton is begging for your business. This app will not only serve to unify the entire communication structure and manufacturing processes of your company across two continents (North America and Europe), but you've also got to make it scalable enough and capable enough to handle phase II: set up a extranet with all the vendors your company does business with to get one hell of a pricing and competitive edge by moving all your procurement to the Extranet a la GEIS. You've got to get your Extranet plugged in properly to that Oracle 8 database that Larry's boys have sold your company while making sure that Phase I and II are accessible to anyone inside the company. And by the way, did the CEO mention phase III?

He didn't? Well, I'll step in for him and give you the coup de grace: You'll be moving all of your manufacturing processes to BTO in 36 months, and not only that, your entire product line will be moved to the web to be built-to-order. Also, your entire supply channel procurement process will be web-i-fied (with a capital W-E-B). Your existing sales channel will still get to sell product, but you want to transition your channel to a service and consulting channel while you make the big bucks on your product line.

Feel the pressure. Wait, says the CEO and CIO, there's just one more thing:

You have 365 days to complete Phase I. Starting today.

If you fail, the CIO will disavow any knowledge of your actions.

This DVD-ROM will self-destruct in 5 seconds....

Now, before you think, "there's no way," and start calling down doom upon your head, what if I told you a dirty little secret that Microsoft doesn't want you to know: The technology to do this has been shipping for almost 10 years, and it's been used to meet deadlines like this on projects like this. And guess what? Microsoft doesn't own it.

Since this is a user-driven application, let's concentrate on the UI for this article. Now, before you get going, you call up that Arthur Andersen consultant who's been banging on the door to start projecting how much time is going to be spent designing and developing and debugging the UI. Since you know a thing or two about software development, and have read an article or two about how it's supposed to be done, and have even heard of a guy named Fred Brooks, you figure that you've got to get the UI right, above everything else. It will be impossible to change mid-stream, and you've seen too many Windows applications that have had a terrible UI. You believe that you should allow about a month to design and three months to implement and debug the UI.

Bad news: you seem to have found an honest consultant. This guy projects that fully 25% of your total debugging time and costs will be spent on UI issues alone, or tying the UI to the actual back-end logic that will run this app. He projects that UI issues alone will chew up close to six months by itself. Since it's the part of the application that will get pounded on, it will need to be the part that is most thoroughly designed, implemented, and tested. Also, he projects that this 25% debugging time will put your project back three extra months, because all the processing of the application must function seamlessly with the front end. He recommends a two-stage approach: stage one will be to develop a deliverable UI and do a sanity check to make sure that the UI is going in the right direction (four months of development and four months of debugging). Stage two will be two months for a rewrite (leveraging the existing code base) and another two months to debug, so the projection will be closer to 12 months for UI alone.

Not exactly the news that you want to hear. The consultant also projects that this project will be close to 2 million lines of code in length, and the UI will consume close to 750,000 lines by itself.

Here are his projections for UI issues:

750,000 lines of custom UI code
4500 defects introduced because of UI issues
492 programmer-months involved in UI
$250,000	1 project leader/system architect ($250K/year)
$1.6 million	40 cheap programmers will need to be hired - (avg cost around $40K/year)
$75,000	1 build/source administrator
$16,984	44 Visual C++ 5.0 seats
	(Open License - Level C) (Source server does not require Visual C++ toolset)
$2352	4 Windows NT 4.0 Servers ($588 per server - Level C)
	1 Server for programmers
	1 server for source code maintenance
	2 servers for build machines
$2296	81 NT 4.0 client access licenses ($28 per client x 2 servers - Level C)
$8856	41 NT 4.0 Workstation copies ($216 per client - Level C)
$164,000	41 workstation-class PCs @ $4,000 per workstation
$40,000	4 server-class PCs @ $10,000 per server
$300,000	4 system administrators @ $75K/admin/year
$20,000	lost time due to Windows "futzing" (20 hours @ $20/programmer-hour x 41) + CVS setup/access
$115,200	lost time due to Windows NT re-installs/total crashes/garbage-laden registry issues1
	(This works out to about 2.88 programmer-years wasted re-installing NT, or 1,051 programmer-days, so let's go ahead and say that three of your programmers aren't doing anything).
$46,000	$1,000 hiring cost x 40 programmers + 4 sysadmins + 1 project leader + 1 build/source admin
$500,000	250 builds/year (One 8-hour build per work day @ $250/build-hour)
	(3 hours per build day is spent compiling UI code - $187,500)
$2.08 million	5 consultants' fees, covers UI requirements, analysis, specifications design, writing, and testing. (12 months' time @ $200/hour x 40 hours/week)
P.S. If you want to factor in the project leader's downtime for re-installs at the same percentage, he costs the company $17,280 for 18 days of downtime spent in re-build mode. Just add $17, 280 to the total below.
Total Cost: $5.22 Million
Time cost:
stage 1:	4 months programming + 4 months debugging (standard 40 hour weeks)
stage 1.5:	1 month UI testing
stage 2:	2 months programming + 2 months debugging (standard 40 hour weeks)
Programmer time cost:
	492 programmer-months spent in development
	164 programmer-months spent in debugging
	1,051 programmer-days wasted, or 2.88 programmer-years wasted in NT rebuilds or 34.5 programmer-months wasted (I guess NT stands for No Time)2
Adding wasted time to the projected time total, your UI development will take about:
~13 months	12 real months of productivity + 18 days of programmers sitting around doing nothing (and that's assuming that these deadlines will actually be met).

Ouch! Guess that CIO job isn't going to be yours, and you won't be reporting to the CEO directly any time real soon. Just for added salt in the wound, the honest consultant tells you that you might as well go ahead and expect to run at least six months behind schedule for the total project (and that's if everything goes according to schedule). So you're looking at 18 months from today to final delivery, and the company wants to start shipping in 12.

What do you do? You still have a job to do. Firing the consultant doesn't help when you know that he's telling the truth.

What do you do?

Fortunately for you, one of your friends at MCI knows something about these kinds of issues. After all, Friends & Family (a little app developed in NEXTSTEP) is what pulled MCI into the big time (You could call Friends & Family MCI's tractor app). Your friend starts telling you a little bit about the database access and control issues that came up (not unlike your database access and control issues). He tells you about this fantastic tool called Interface Builder.

"Interface Builder?!" you exclaim. "What's that?"

The best thing about a tool like Interface Builder is that it doesn't do code generation.

"Really?" you ask. Yes. It doesn't do GUI code generation, and its objects generate no code. No code means no debugging. No debugging means six months of debugging downtime suddenly turned into six months of real time given back to you. What's more, it's so powerful that a couple of really good OPENSTEP programmers can turn your interface hell into interface heaven.

Let me explain: Interface Builder lets a programmer totally prototype and re-use interfaces rapidly for any project of any kind. Because the visual objects of the UI are already running when they are created with IB, they don't need to be fixed or modified or compiled to handle your custom business logic (i.e. the back-end). What that means is that instead of spending real time and money on a prototype cycle and real time and money on a development cycle and real time and money in a rework cycle, you can instead spend less than half of that real money on one UI development cycle. What's more, you don't have to spend any time or money on a debugging cycle for either the prototype demo or the development UI. You get free time!

So, you're thinking, how do I get this? Worse yet, I've got to deploy this on Windows NT, and you're telling me that it runs on OPENSTEP? What's this Rhapsody thing I keep hearing about?

Well, your friend says, that's the best part. OPENSTEP Enterprise is already available today and Rhapsody will be available tomorrow. What's great about both environments is that they let you develop and deploy for Windows NT. That way you don't lose your shrink-wrapped apps (Office '97). You get to manage one source code tree and deploy to Windows NT. And because you don't have to spend all that time developing, generating, debugging, and maintaining all that UI code, you get a huge savings.

So you go to your honest consultant and tell him to recalculate the numbers. Tell him that he only has to hire three programmers instead of 40, and he needs 1/3 of a system administrator, 1/3 of a source code administrator and 1/3 of a build administrator , because of OPENSTEP/Mach's rock-solid stability and low-maintenance life-cycle. You also tell him to get the best OPENSTEP programmers that money can buy.

So he comes back with these numbers:

0 lines of custom UI code
0 defects introduced because of UI code
16 programmer-months involved in UI
$250,000	1 project leader/system architect
$0.4 million	3 intermediate-level OPENSTEP programmers will need to be hired (average cost around $130K/year)
$3196	4 seats of OPENSTEP/Mach for Intel
$20,000	4 seats of OPENSTEP/Mach programming tools
$799	1 seat OPENSTEP/Mach - build server
$5000	1 seat of programming tools for build server
$799	1 seat OPENSTEP/Mach - source server
$16,000	4 programmer workstation PCs @ $4,000 per workstation
$20,000	2 server PCs @ $10,000 per server
$75,000	1 system/source/build administrator ($75K/year)
$2000	lost time due to OPENSTEP/Mach futzing + CVS setup/access issues
$5,000	$1,000 hiring cost x 3 programmers + 1 sysadmin + 1 project leader
$1000	downtime of programmer workstations for miscellaneous reasons (failure to install/time wasted rebooting/etc)
$312,000	250 builds/year @ $250/build-hour
	(subtract 3 build-hours per build because UI code does not need to be re-compiled)
$128,000	1 consultant's fees, covers UI requirements, analysis, specifications design, writing, and testing. (4 months' time @ $200/hour x 40 hours/week)
Total Cost: $1.24 Million
Time cost:
stage 1:	2 months development + 0 months debugging (standard 40 hour weeks)
stage 1.5:	1 month testing
stage 2:	2 months development + 0 months debugging (standard 40 hour weeks)
Programmer time cost:
	16 programmer-months in development
	0 programmer-months spent in debugging
	4 programmer-days wasted installing/configuring Mach
Total time: 4 months of real productivity + 1 day of programmers sitting around doing nothing

The honest consultant gives you the numbers. After doing some quick calculations, you realize that approximately 76% of the UI money slated to develop the project in Visual C++/NT will be saved. Here are the calculations: ( $5.22 million - $1.24 million ) / $5.22 million × 100% = 76.25% cost savings. When you look at the time savings you see why IB is called a killer app:

Visual C++-based GUI solution: 656 programmer-months.
IB-based solution: 16 programmer-months.

Time-savings: 97.5% of the total programmer-months are saved.

CIO position, here you come... and in plain English, too.

I cite Simson Garfinkel for a couple of different reasons. First, he is no dummy. He wrote a NEXTSTEP programming book. Ahhh, you may think he's biased, but then you learn that he torched his black cube (literally) a while ago. Second, he moved to Windows as his primary platform because the Mac didn't get the software updates or releases that he needed. Third, if this guy, who's done a lot of computer work and programming, has to spend three days a month re-installing and rebuilding his NT system from scratch (and he's a smart guy), what chance do regular people have?

I'll be generous and say only 50% of all programmer workstations suffer from 3 rebuild days per month. That still breaks down to (40 programmers × $160/programmer-day × 36 rebuild days per year × 50%) = $115,200.

And no, the system administrators are not going to work weekends doing rebuilds. They only do server work on weekends!

² Some people may argue that you're paying for futzing anyway by making programmers salaried. True. However, I'm breaking out the Windows futzing and rebuilding numbers so people can actually see what kind of money they could potentially throw away on a vertically-integrated Microsoft-only solution.

For the uninitiated, the futz factor is the time spent wasted doing tasks that a more stable system would not force on you. Things like configuring a system, fighting with device drivers, rebooting after a system crash are all time wasters categorized as "futz". The futz factor includes, but is not limited to:

1. rebooting after installing an app
2. rebooting after removing an app
3. rebooting after you use an app in order to re-install it
4. rebooting because your threads and processes are out of control
5. rebooting because your debugger's hosed and you have a runaway process
6. rebooting after editing the registry (something I have yet to see on any other OS)
7. rebooting after fixing environment variables
8. System rebuilds, which are given a whole day, and result in the programmer wishing he was using something else other than NT.