Enthused About: Software Engineering

This is a "classic" passion of mine - software engineering. Academically, my undergrad and Master's degrees focused on this topic, and I've dabbled in it professionally (though it didn't end well, as you'll see). Here's my story, and some lessons I've learned about software engineering.



I started programming around age 13. I checked out a book from the Clinton Public Library (I think it was "Structured BASIC Programming with Technical Applications for the IBM PC", by John Blankenship - it was blue, and if the Jackson-Hinds Library System's Online Catalog is to be believed, it's currently in the discard pile). As you may be able to tell from the title, this book would bias my approach to programming (forever). It had all of these diagrams, big flowcharts that decomposed into other flowcharts. On a weekend trip to Columbus, I used the flowchart approach to design a Monopoly game on a 286 computer in GWBASIC ... it had a killer, 8-flowchart design, but my programming skill at the time didn't let me finish it.

In high school, I was the third wheel on a programming team that placed in a couple of competitions. (All three of us would go on to Mississippi State in 2002, and the other two now have real jobs.) In preparing for our second year in the competition, one of my teammates described our roles as something like "One of us works on coding the next problem, one of us debugs and submits the current problem, and Bryan, you do whatever it is that you do ...." Not that my role wasn't important - I basically was Google-master, and I would write some notes about how we could solve the problems. I called it "algorithm development", but could have easily had the title "Chief Software Architect and Director of Research." And to be honest, I sucked at programming, so this was a good fit for me. I think we placed third that year.

I went to MSU in 2002 and they had this new degree called "Software Engineering". I had very little idea how SE differed from regular computer science (I never connected it to my prior experience with diagrams and flowcharts), and it had just graduated the first two students, so I double-majored in that and computer science just in case. Throughout my degree, they were tweaking the program, but basically I took an overview class in software engineering, a class on software testing, a class on software architecture, and a class on software project management. These classes led me to believe that software engineering was all about documentation - really thick, IEEE-standard documentation.

During the first 18 months or so of my Master's degree, I worked on the side (moonlighting, I guess you could call it) for an investor. He had a couple of web site ideas, and they were complex (i.e. not static, cookie-cutter sites). I failed miserably at this, and was quickly in well over my head. Suffice it to say that the projects didn't end well, and I regret even getting involved with them, for the investor's sake. If I had the means, I would have refunded all of the money he ever paid me. This was a low point for me - I sucked at the very thing I had been trying to learn how to do ... :-/

Finally, I started to change the way I thought about software engineering to a broader context - software engineering is about developing software in the best way possible. In a massive DoD project, it will have thick, IEEE-standard documents, perhaps. In an investment venture, you should probably do some design, but the focus is to get something for the customer to see as soon as possible. Every situation is different, and knowing how much engineering overhead is appropriate in a certain scenario is critical.

I'll sum up my new view with some ideas:
Requirements:

• Understanding software requirements might be the most difficult part of the SE lifecycle, and it is definitely the most important.
• Understanding stakeholders and their concerns is important.

Design:

• Software design is about understanding viewpoints - logical, development, runtime, and physical - and the interaction between them. (See The 4+1 Model.)
• Document the design well enough to proceed with development, and only more stringently if you plan on reusing elements (i.e. as an architecture).

Implementation:

• Programming doesn't happen in isolation, at least not anymore - it happens in teams of real people.
• Tools and languages are only helpful if you know how to use them (it helps if they're easy to learn and easy to use).

Quality Assurance:

• Customer involvement is necessary to define "quality".
• QA should be a full-lifecycle activity, and not something you only do by executing code.

Management:

• Rigid models can be recipes for disaster, mostly because requirements can change.
• Estimating the cost of software development is incredibly difficult, and might be impossible. At best, it takes mounds of data and/or experience to get right.
• Managing the customer is more important in most cases than managing your developers.

These ideas are at the center of my current research interests. If we are going to make software engineering easier or better in some way, it has to start with the human element. Why is software development so hard for us to get right? What kinds of models, methods, and tools actually make it easier to develop software instead of making it more difficult?

THAT, my readers, is why I am enthused about software engineering.