What is a Software Engineer — Understands & Evaluates tradeoffs

In the fall of 1996, I was sitting in my first classes at the University of Missouri – Rolla.  I was there to get a degree in Electrical Engineering, and was taking a few basic engineering classes.  One was an engineering design class.  The class walked us through a few basic engineering software packages, like Autocad.  Additionally, there was a design competition at the end of the semester.  We were split into groups of 5 or 6 students and given various specs to follow.  

The goal at the end of this semester was to have a pedal-powered vehicle that met certain height and width requirements, and all had to be done for under $150.  Additionally, it had to maneuver around a course that the professors would construct. At the first meeting of our group we discussed what our backgrounds were.  We had one guy (we’ll call him Jim, because I can’t remember his name) who had done a lot of mechanical design, and general shop type stuff growing up.  We made the decision to make him the project lead.  The idea being, he could help guide us along the path, but since all our grades were riding on this, it was still a democracy.

As we start talking about our vehicle, a few of us want to hit the thrift store and grab a couple bikes to cannibalize.  Jim’s not crazy about this idea though.  His focus is on the end of the semester competition.  He wanted to win it, and he was worried that thrift-store parts just wouldn’t work out.  He pitched the idea of getting some “aircraft grade aluminum pipe” that would be strong and light-weight.  He knew a guy who could weld it for us (since apparently a normal welder wouldn’t work.)  We all decided this was a terrible idea for a few reasons.  First, it would not be cheap (something like $130 of our $150.)  Secondly, it was JUST the framing.  We’d still need to acquire tires, gears, seats etc.

In the end, Jim ordered the aluminum against our wishes.  It came in on Monday afternoon, and he dropped out of school Tuesday morning. There were now 4 of us left with $130 of aluminum, no idea how to get it welded and no real money to buy anything else.

Jim might have had the best design ability in our team. From talking to him, I think he had a better understanding of materials, welding and structures than I did.  However, what he failed at was understanding the trade-offs.  He only knew that this aluminum would be strong enough to hold any of us.  He knew that it was lighter than anything we could get at the thrift stores around town.  However, he didn’t pause to think about what this aluminum would do to our grades.  After all, for the other 4 of us, we were more focused on getting a good grade in the class, than having the lightest and fastest vehicle at the end of the semester.  

Sadly, trade-offs are not limited to the classroom.  The last project we started at work required interfacing with SQL Server 2008. When we started working on the DAL, EF Code First was in beta.  We knew we wouldn’t be releasing our code for a minimum 6 months.  Additionally, we were trying to keep all of our business logic in the C# code, and not in stored procedures.  As a result, we used EF Code First as our ORM.  After a few meetings we realized we needed to use the new hierarchyid data type.  The problem is that EF doesn’t support this data type. As a result we were going to need to write a couple stored procedures to interact with this data type.  The problem was, EF Code First didn’t have support for stored procedures. 

So we were faced with a dilemma:

• Should we convert our DAL to Entity Framework 4
• Should we find a way to not use hierarchyid (and therefore not need stored procedures)
• Should we use EF Code first, and then standard ADO.NET to access the stored procedures

Each of these have advantages and disadvantages.  Converting to EF 4 lets us have stored procedure’s in the Database Context.  However, it also has a huge xml mapping file.

Getting rid of the hierarchyid lets us use EF Code First, and it’s clean approach to ORM.  But it impacts performance as we create a Parent/Child table with joins to create a tree.

The third option lets us use EF Code First, and still have stored procedures, but now we have multiple coding techniques in the DAL.

In the end, we chose the 3rd option, because the 2 or 3 people who would be working on the back-end felt comfortable using ADO.NET for a few specific methods.

But what’s important here is that we actually evaluated each option.  Each of the 3 were very real possibilities.  We didn’t just discard any option because we didn’t like it.  We investigated the advantages and disadvantages of both.

That’s a key aspect to engineering in general and software in particular.  If I’m working with you, I want you to look at using different packages as well as different coding techniques and understand which one fits best for the problem at hand.

Oh, and the engineering competition?  In the end one of the other guys was in work-study and was working in the Physics building, where met a master craftsman named Charlie (it’s telling that I remember his name, but not the guy that dumped us.)  Charlie not only had the equipment to weld for us, he gave us some design ideas to help us make sure it was strong.  Our professor was more than understanding, and we ended up with an A on our project.