Most Read This Week
A Developer's Story Part 2
A Developer's Story Part 2
By: Hal Helms
Feb. 28, 2003 12:00 AM
In last month's article, I introduced you to a company with a project in jeopardy. When I was called in to analyze the situation, I discovered that the project was a major revision; the first version had been very successful, but now the company was running into problems. I promised the CIO that I would make a presentation to his key development team. In preparation for that meeting, I found myself at a local store, Frank's House of Models...
Frank led me to the back of his small store, filled to the ceiling with models, some of which were so old that they must have been made when I was a kid. "Let's see," said Frank. "You're looking to build a model world - is that it?"
"Yes," I told him. "I want to illustrate to a group of businesspeople and programmers the idea of a scale model as a successful development paradigm." Paradigm? Had I really said that? Who spoke like that? "You know - a better way of building software."
"Well, I don't know anything about software. It seems like every time I use software, it's either crashing or fighting me. I bought an accounting system for my business. Here..." He pointed vaguely at the store. "But I don't know, it just doesn't work the way I do. It's my fault, no doubt. But I do know a good deal about models."
I spent the next half hour with Frank as he took me on a tour of his store. It turned out that some of the models were decades old. But they were in their original shrink-wrapped boxes and were highly collectible, their prices reflecting this. However nostalgic the old models made me, I had to admit that the new models were far superior in fit and finish to the older ones. He showed me photos of some finished model cars. I really could not tell that these weren't real. The photos gave me an idea.
"Say, Frank," I said. "I want to ask you a favor. Do you suppose that I could borrow these photos for an hour or so? I want to make color copies of them at Kinko's." "Well, there's one about a mile and a half down the street. But you just want copies?"
"Yes. I'm not a model maker, at least not models like these. I could never hope to get the accuracy of detail and the beauty of these. But these photos represent exactly the point I want to get across. I'd be glad to pay you for the use of the photos."
"You don't need to do that," Frank said. "Just be sure to return them."
"An hour, tops," I promised him. We picked out photos of models that Frank and his son had made: a Ferrari F60 racecar, a Ducati 996 motorcycle, and an F/A-18 Hornet attack fighter aircraft. I found the Kinko's and 40 minutes later returned with Frank's originals. "Say, while I'm here," I said, "do you suppose you could show me something that a novice could build? I'd love to try doing this with my son."
Frank was more than happy to assist me with finding just the right car. Of course, I needed some tools and supplies; after all, what's a craftsman without the proper tools? I may have taken this a bit too far though. Certainly when I paid the bill for my 1/8th scale Aston Martin DB5 James Bond car (with working weapons!) and enough tools and supplies to build the real thing, I decided that it would definitely be worthwhile trying to convince my accountant that since the purchase of the model had been inspired by a business need, it would be perfectly legitimate to write it off as a business expense. Until I got an answer, I thought there was no reason to trouble my wife with this particular matter.
Back at my hotel, I began to sketch out some ideas. I quickly found photos of the real counterparts of my models on the Web and sent these to Kinko's to have color-copied as well. I prepared more questions for my clients and decided perhaps it would be wise to call my accountant at home. After I explained the situation and my creative interpretation of this as an investment, Vicki laughed out loud. "All I can say is you better use this for a presentation; the IRS sort of frowns on the inspiration thing. Either that or you can explain to Susie why you spent - how much was it again?" These accountants! Have they no souls?
When the day for the presentation dawned, I had my photos, my PowerPoint - but no Aston Martin model. The CIO was present. The lead architect, the developers, and several of the project managers were all there. I began by passing out the photos in pairs - the model followed by the real thing. Then, ignoring the photos for the moment, I began my presentation.
"First," I said, "I want to say that it's obvious from the research I've done that there's a high degree of commitment from each person on the development team. This is not a case of not caring and certainly not one of incompetence. I know that many of you are frustrated by the situation - working very hard, but with too few good results to show for it. If it was easier to pinpoint the problem, to find the "real culprit," I think we'd all be relieved.
"But it's not. When you created the first version of this software about three years ago, you did all the things you read about. You talked with the users. You interviewed your customers. You watched how they worked. And from this, you created a requirements document.
"That requirements document was clear and unambiguous. From talking with the end users - the ones who participated in the original process - they spoke highly of the project management and development team. When the software was delivered, it was exactly what they asked for. And you all were heroes."
"Oh, for the good old days!" said one developer, as everyone laughed.
"Then what is the problem?" asked a project manager.
"The problem is just that - you listened to the users and gave them exactly what they asked for."
"That's the problem?" she asked.
"Yes, I'm afraid so," I answered. "By concentrating on their requirements and then using a process of functional decomposition to ensure that each requirement was met, you were able to deliver a product that did exactly what the users wanted - at that time. Had this been a movie, we could have ridden into the sunset and had the screen fade to black.
"But it's not. Within three months after the software was delivered, changes to existing laws required that the software's internal logic be changed to account for these new requirements. Then, two months later, the company reorganized and new requirements meant new changes. But then you acquired another company and had to roll their data into your systems. That meant more reworking of the software."
"I knew it," another person said. "It was that damned merger - that killed us." Several people nodded in agreement.
"No, it didn't," I disagreed. "What's hurting us is that the software was designed for a single moment in time. The requirements were frozen and the software was built for one thing - to meet those requirements. We all know that life isn't static - but our software is. No one could have predicted the changes to the law or the merger or any of the changes that occurred..."
"But we could have predicted one thing - that changes would occur," said the CIO.
"Yes. Exactly that. We know that to a certainty. But you'd never know that from our software. And when I say, 'we,' I'm talking about the great majority of software that gets developed."
"How can we develop software then? When we know there will be changes but don't know what they'll be?" asked one of the programmers.
"Take a look at the photos I passed out. The first one is of a Ferrari F60. The next one is also of a Ferrari F60, but with a difference. The next one is a Ducati motorcycle, followed by another picture of the same model Ducati. The last one is an F/A-18 Hornet strike fighter. And then another Hornet."
"I don't get it," confessed the CIO.
"I don't either," said a project manager.
"Of the three sets of photos you have, one of them is a photo of a real vehicle and one is a photo of a model."
"A model? Like a toy model?"
Thinking of the bill for my "toy," I responded, "Not a toy - a faithful scale model. They're remarkably accurate."
"Yeah, I can't see the difference," said one of the programmers. "But how does this affect us? We don't build models."
"That's just the problem. We're building software machines that do exactly what the user asks us to do - but that can't respond to the new things that users want to do.
"Software looks very different to all of us in this room than it does to end users. We know what goes into it. We know how hard it is to build. We know the technology that goes into it. We know so much, in fact, that we forget that to users, the interface is the application. When they see something on their screen - an invoice or a user record - they assume that they're looking at a real invoice, that the user they see is somehow alive in their computer."
"But that's crazy!" said one of the programmers. "The invoice is just a visual screen of information in a database. It's not alive."
"No, it's not. But users aren't that sophisticated. We show them an interface and they believe it. They believe it so much that they naturally want to do things with what they see - they want the software counterparts to act just like the real thing.
"And that's just what we do with good scale models. What is so engaging about the model vehicles in those pictures is how amazingly lifelike they are. You can turn the steering wheel and the wheels turn. You can open the hood and the engine is faithfully represented. You get the sense that if you could shrink yourself down to Lilliputian dimensions, you could get in it and drive away."
"My son does models," said the CIO. "Some of them are pretty astonishing. But how exactly does this relate to our software?"
"We don't think of ourselves as model builders. We think of ourselves as algorithm-makers or data-manipulators. But until we start designing software to better reflect the real world - until we build scale models of the real world - we're going to run into this disconnect, what engineers sometimes call an 'impedance mismatch.'
"Developers think they're creating screens and reports; users believe they're looking at the face of something much richer. So when the requirements of the real world change, they expect that the little invoices that live in their computer will change too."
"But building things in software is hard, harder than the real world sometimes," argued a programmer.
"I agree with you," I said. But some of the reason that it's hard is because our design is clouded by thinking in terms of databases and algorithms and not enough of the world as the end user sees it. It's a bit like viewing humans as a collection of DNA molecules. On a certain level, it's true, but it's at the wrong level. The wrong level for humans to interact. At the human level, we care about others' intentions, passions, thoughts, emotions.
"The problem with our software is that the user sees something - an invoice, say. But, as Gertrude Stein once wrote about Oakland, 'there's no there there.' There is no invoice that we can go to. The concept of an invoice has to be assembled from bits of data in various tables and different functions that operate on that data. The data you see on the screen is a trick, an illusion rather than arising from the invoice itself."
"You're speaking as if we really could build software that's alive - scale models that are alive. Is that what you're saying?"
"Not truly alive, no, but we can build faithful scale models. This is why object-oriented programming has swept the development world. Objects are those scale models. Before you start working on database table structures or work on algorithms, you determine what entities will inhabit the universe you're creating. You determine which ones will know about other ones. You decide how they will communicate; what each will be able to do.
"Object-oriented software development is about creating scale models of the real world. Data and algorithms are important, of course, but only to the degree to which they make the scale model more faithful in its representation of its real-world counterpart.
"What's important for us to see is that without this correspondence between real-world entities and software entities, we'll never be able to keep track of the complexity and the dynamic nature of the real world. What's important for us to see is that object-oriented development can help us build software that is more maintainable."
I turned to the CIO. "About what percentage of the total life-cycle cost of your code is used for maintenance?" I asked.
"It varies, but from 70-90% - something like that." The eyebrows of several people went up.
"That's in line with most studies I'm familiar with," I told him. "How many of you developers realize that?" Only a couple of hands went up. "The problems that you're having is because the software that's being built is great, but only if things don't change very much.
"But things do change, and we all spend an enormous amount of money and time and frustration trying to patch software together to keep up the illusion that the users want to see...that we've convinced them they should be able to see. They believe it's real, but we don't. And we don't build our software as if it was."
"You really think that an OO approach can help us?" asked the CIO. "I mean, we're not building Microsoft Word here."
"Look at virtually all modern computer languages and they're object-oriented. I mean, good grief, even languages like COBOL have OO extensions to them. It's not just a fad. Right now, OO development offers us the best chance for writing software that is successful in the long run.
"That's true of small-scale projects and of enormous-scale projects. Object- oriented design encourages a separation between the model that underlies everything and the view the users see, allowing either one to change independently of the other. It's not a magic bullet..."
"Nothing is," the CIO remarked.
"No, but it can make a very, very significant difference in how sturdy our software is. Or maybe sturdy isn't such a good word. Maybe how flexible, how malleable, how adaptable our software is."
"Does that mean we need to move to Java then? Or the .NET world?" a programmer asked.
"The choice of a language is a complicated one. But the language isn't a magic bullet either. I've seen a lot of Java code that is nothing but procedural code stuffed into classes. Larry Wall once joked that real coders could write assembly code in any language.
"It's not the language so much as the way we approach design. You're doing most of your work in ColdFusion. CFCs offer some of the benefits of object orientation. And even if you decide to incorporate other languages such as Java or one of the .NET languages, you'll need to go through the experience of learning to think in objects. That just takes time. And practice."
One of the project managers who had been silent then spoke: "When I was learning French," she said, "I had to work at it for a long time. At first, I was translating everything from English to French. It was slow and clumsy and frustrating. But then after a long time, something happened and I actually started to think in French. That's what I think of when you're talking."
"That's a perfect analogy," I told her. "That's exactly what it's like moving to designing OO projects. At first, we keep getting mired, worrying about implementation details. Because there's so much we have to know - technical stuff - it's completely understandable that we view the world from that level."
The project manager speaks again. "But you're saying that's like living at the DNA level. Or like me thinking in English, but trying to speak French."
"Yes. If we're to make real progress, and not experience the frustration of projects that can't be maintained, we have to make that switch to viewing the world in objects to thinking of ourselves as model makers, as creators of virtual universes."
We talked a good deal longer, and the longer we talked, the more noticeable a change in the tone of the room became. We had gone from being defeated to being hopeful. Finally, the CIO spoke up. "I say we try it. He's right: the world has gone to OO and there's a good reason for it."
"I'm up for learning something new," said the chief developer.
"If it will help my customers, I'm all for it," said a project manager.
"And you'll be able to help us with this?" asked the CIO.
"I sure will," I replied.
It was a great meeting, but as I got into my car, I remembered the scale model I bought - and all those tools and supplies! Oh well, I figured I'd just explain to my wife that this was sort of a very late or very, very early Christmas present! And...maybe a birthday present thrown in, too.
Wait a minute...I pulled out my cellphone and dialed my accountant. "Vicki, if I were to do research on a book or article, I could write that off, yes?"
"What kind of research?"
"Any kind. If I was writing about France, I could go to France, right? If I was writing about cooking, I could buy tools and stuff?"
"Oh, this is about that stupid model you bought. Well, yes, you could expense it - if you were writing on models. But you're a programmer, Hal, not a model maker. How could you ever end up writing about making models?"
Reader Feedback: Page 1 of 1
Subscribe to the World's Most Powerful Newsletters
Today's Top Reads