Developer.com content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
Introduction
Mike Groher and Don Gardener let me write my first few lines of code while getting paid back in the 1980s. The code was in Databus on a Sunbelt mini-computer with Winchester drives and 256k of RAM. I have been fortunate enough to get to sling code pretty much for the last twenty years.
Because I have enjoyed solving technical problems so much, I have made an independent study of what works and doesn’t work. Because it’s an independent study, I am permitted to draw my own conclusions and support them. If you will indulge me, I hope you will find this perspective useful: Successful projects build core first and cosmetics last!
Why the Core is Critical
Few ideas are completely original. In some book I have read (or maybe several books), it was written by a famous person that presentation composition is the weakest for of development, data composition is the second weakest form of development, and building the core business capabilities is the strongest way to build software. (If memory serves, I first came across this idea in 1992 in Grady Booch’s book on OOA/OOD.) Another way this has been stated is to build the onion in layers from the inside out—sounds like something Jim McCarthy wrote. Paul Kimmel and Larry Zippi call this “Core to Cosmetics.”
With many popular books and articles on software development out there, I am always surprised that many projects start with the GUI first. It’s understandable in one sense: Customers see GUIs, not classes, and everyone understands GUIs but few people really understand classes or even care. The basic idea is that neither the customer nor even many project managers believe in progress without the visible presence of progress easily digested in the form of GUIs. Here is the rub: GUIs aren’t hard anymore.
Graphical user interfaces are not hard to assemble because visual components are pretty well established. GUIs do suck up a lot of time because they encourage constant tweaking and dinking, moving TextBoxes, aligning Labels, and similar low-value type operations. Throw in customers suggesting tweaks and it’s easy to see how GUIs can become a time suck. Unfortunately, time is a precious commodity in limited supply.
The next problem with GUI composition is that it promotes a style of development that results in figuring out how to move data to and from the GUI. Weak stuff. Finally, GUIs themselves don’t solve any particular business problem.
Similar kinds of arguments can be made about databases. The persistence layer typically represents some of the data storage needs and some of the plumbing necessary to satisfy the requirements of relational database technology.
The Core—what is typically called the business problem solution—is the only code that represents the solution at its essence. Current best practices even encourage defining business objects in the domain of the customer with properties, behaviors, and elements that reflect the problem to be solved. This is why the core has to come first. The Core aids in figuring out what needs to exist in the persistence layer and the core supports putting nay presentation layers on top of it. The code core and you can attach a cell phone, PDA, Web client, WinForms client, or anything else you need as the front end.
It’s not just the core that is critical. It is core prioritized by complexity, risk, and value that is critical. Every software project has a reason for being. Solve the primary problems first and very early on you have functional software that solves a problem the customer needs. It is worth noting that if you talk about risk and complexity, you may scare the hell out of your customer and undermine their confidence in you. It’s better to talk about the core value (but you know you mean risk and complexity).
Why Cosmetics Come Last
A lot of what we currently think about software development is taken from age old building architecture. Take a house, for example: The foundation and framing happens pretty early on. Window treatments and landscaping happen very late. With trucks and workmen trudging all over your future lawn and your future house, it make sense to wait for finish work until all the dirty work is done.
There are actually a lot of reasons why cosmetics come last. Any time requirements change, property values, database fields, or almost anything that has a visual representation changes the presentation layer will change. Do the presentation last!
Now, it is very unlikely that a customer will wait until the end to see what their application will look like, and the customer will want some input on the finished appearance. Handle this with lightweight prototypes but don’t spend a lot of time on this. Use prototyping to establish a general look and feel and get back to core.
Summary
Every project runs out of time. After twenty years, I have found that if you build core first the customer will perceive that they are going to get a product, and this success-perception paves the way for the remaining decisions that are generally less important.
Mitigating risk by building core first means that you will have tackled the hard problems and they are less likely then to cause you to stumble later. Think of building core as the long hard ride up the mountain and building the cosmetic aspects last as the fun, fast sprint down the mountain.
Finally, if parts of the GUI are core—for example, it some new thing that is new or tricky—you might have to build that as part of core. Core doesn’t always mean business rules literally; core generally means complex and risky and usually risk is in capturing the right business rules, but not always. Identifying core and starting there is the way to go.
Thanks to Larry Zippi. Through our discussions “core to trim” and “core to edge” evolved into “core to cosmetics” and, as I told Larry, I like the alliteration.
About the Author
Paul Kimmel is a freelance writer for Developer.com and CodeGuru.com. He is the founder of Software Conceptions, Inc, founded in 1990. Paul Kimmel is architect for EDS, an HP Company. You may contact him about article questions at pkimmel@softconcepts.com.
Check out Paul’s most recent books, LINQ Unleashed and Teach Yourself the ADO.NET Entity Framework in 24 Hours (coming Spring 2009).
Copyright © 2008 by Paul T. Kimmel. All Rights Reserved.
