Modelesis

As head of the Bachelor of Science in Software Engineering degree at the Santo Domingo Institute of Technology (INTEC), one of the questions I field more often is the difference between this degree and our BSc in Computer Science.  This  second degree is actually named “Information Systems Engineering” (both at INTEC and generally at all Dominican universities), but is typically accredited as a BSc in CS internationally; a recent curricular reform may change that, though, as it is now based on the ACM/IEEE guidelines for Information Systems programs.  I have a variety of resources to answer the question of how they differ, but recently drew on a long tradition of cooking and software development parallels and came up with an explanation that seems to satisfy people more than previous ones.

Cooks: Their Birth and Immediate Concerns

There are several good analogies between cooking and software development.  I’m particularly fond of Joel Spolky’s “Big Macs vs. The Naked Chef” – a strong take on process for the sake of process that, 12 years on, remains just as real and relevant (a testament to Joel’s way-above-average observation and writing skills).  I’m sure there are many other good analogies out there.

Anyway, cooking.  I learned some of it when I lived alone in England during my MSc, but I’d never call myself a good cook.  But I do know a few good cooks.  And I know that good cooks are often encouraged by friends to take on cooking as a way of living.  However, along the lines of Joel’s essay, this entails quite a change for the budding cook.  Before taking it up as a business, our star friend deals with the following in her kitchen:

Just cooking!

(You can go ahead and infer my cooking abilities from my drawing abilities.  It’s OK.)

Once she’s making a living from it, though, there’s considerably more to look after:

The whole enchilada

Without quite leaving the kitchen, our star chef now has to worry about:

• Recipes.  Are the dishes going to be all artsy, changing from day to day based on what’s fresh?  Or do we want to have some sort of predictability in terms of a menu?  How do we balance cost, preparation time and other concerns?
• Ingredients.  A dish includes avocado.  How do we secure a year-round avocado supply?  If an ingredient is not available, can we substitute something else without altering the essence of the dish?  Can we do so to bring down the cost of our menu?
• Presentation.  Much as love enters through the kitchen,  appetite enters in no small proportion through the eye.  Sure, smell is important, but the chef better be good decorating her dishes, or people won’t be as prone to make them justice as they’d otherwise would
• Quality and consistency.  Can we guarantee that dishes will always taste more or less the same?  How do we ensure it?

Heading For The Majors

Ever heard about McDonald’s?  Enter almost any McDonald’s restaurant and, usually near the door, you’ll find a plaque celebrating Ray Kroc.  But who is Ray Kroc?  He’s the man responsible for making McDonald’s the global fast food power it is today.  But how?  Shouldn’t it be called “Kroc’s” then instead?

You see, the McDonald brothers were quite happy with their original restaurant chain concept.  They popularized the “production line”  approach to fast food, and handed out a few franchises.  But it was Ray Kroc, a milkshake machine salesman, who took notice of the opportunity and, first as a partner, then taking over the business, built McDonald’s into the fast food empire we know today. (More over at Wikipedia.)

Ray Kroc’s McDonald’s compares to our friend’s little joint by the corner more or less like this:

The whole Mexican place!

My restaurant business chops are nonexistent, but you get the idea: there’s a lot more to take into account outside the kitchen in order to truly grow and cover all bases.  The purple bit in the center keeps being somewhat, well, central to the entire thing, but there’s a rather large expanse of blue and red encompassing it that needs to be looked into as well.

Moving Back To Engineering

So what has this got to do with our original question?  To me, a lot.  Let’s begin with that basic activity which we sometimes see as central in all computer-related professions:

Bliss…

But of course, as any junior (and even some sophomores) soon begins to realize, there’s much more than programming to the task of producing software:

Not as blissful, but necessary

Our budding code monkey now realizes there’s a lot more to keep an eye upon in order to produce great software, even though it all revolves around, well, making software.  This, in my mind, is the quintessential realm of the software engineer.  She is every bit like a sports coach: not only a skilled practitioner, but keenly aware of how she and her team carry out the software development process, in order to know what to keep, what to ditch, and more importantly, why.

Interestingly enough, there’s plenty of room to work here without actually programming.  Business analysts, technical writers, testers, are just three of the many roles that the software team requires, that still revolve around the development process but are not intrinsically bound to the software construction activities in the same way that, say, design and programming are.

Of course, there’s much more to IT than just software development:

A systems engineering perspective

This, in my opinion, is the systems engineering/information systems context.  It is a superset of  the software engineer’s realm.  Much like general medicine as sole medical practice gave way, by virtue of specialization, to branches such as neurology, hematology and the like, the software development process demanded, and was later met with, an engineering discipline of its own.  But information systems comprises much more, and an information systems engineer is capable of orchestrating and expanding into much more areas than a software engineer normally would.

Of course, information systems engineers can also program if they like (at least in our curriculum).  And the facts that software engineering as an undergraduate program is so young, and that many organizations are using “software engineer” as a position or title to be filled by people with many different academic degrees, contribute in no small way to the confusion surrounding these degrees, which in fact are of course closely related, but still specially unique from each other.

In the hope that this humble analogy helps clear the confusion, I’ll leave it at that – I suddenly feel hungry and need to go grab a bite.

Comments

Warlin Garcia - April 28 2013 9:47 PM

Excellent analogy!

Juan Carlos Garcia - April 28 2013 11:01 PM

Really enlightening