Geeks With Blogs
John Hines' Software Process Blog
A blog on Agile software development and Scrum
Software Engineering is the rare field that produces a product that is never consumed nor decays.  A working piece of software will last forever as long as there is functioning hardware on which to run it.  I once attended a class where a student honestly said that the act of writing software made him feel "immortal".

But most programs (thankfully) don't last forever.  Why?  Because their quality is so poor.  Businesses often treat software like a disposable product because the act of maintaining it is so expensive.  In other words, it's more cost-effective to write new code than to refactor existing code.  We spend our time fixing bugs, bolting new features on top of a bad design, or starting from scratch instead of refactoring existing code into something new.  But...why?

Simply put, my experience has shown me that most bad code is a result of bad engineering.  Many Computer Science graduates haven't been taught good design skills.  Many Software Engineers have spent their careers as Software Maintainers, spending little to no time writing new code.  And managers are unaware that designing new software requires different skills than maintaining it, promoting Software Maintainers to lead the creation of new products, continuing the cycle.

Software Engineering fundamentals are instrumental in fixing the "bad foundation" problem.  It's my goal to share just a few links that I've found useful.

Class Design
  • The Abbott technique (alternate link) is a method from 1983 that famously claims you can parse an English description of a problem statement into a working piece of software.  While it's a stretch to say you can apply rules to get a complete program, you can definitely get an idea of what your classes and many of their members and methods should be.  Perform a web search for "Abbott Textual Analysis" for more guidance on using this technique.
  • CRC Cards are a great next step once you've defined your initial classes.  This will help build out how your classes will interact and exactly what their structure will be.  Best of all, it's an iterative and collaborative process that you can use to get more and more granular.  See the "Reflections on CRC Cards" whitepaper for more guidance on using this technique.
Unified Modeling Language
OK, UML, was way oversold in the '90s.  I know.  It was that decade's Abbott technique - draw a model, get a working program.  It didn't work.  But that doesn't prevent the fact that UML is the standard for describing software composition and behavior.  At the very least, learn these two UML diagrams.
  • UML Class diagram - describes the structure of a class and its relationship to other classes.  Just knowing the difference between a solid line and a dashed line can get you pretty far.
  • UML Sequence diagram - describes the interaction between classes or objects.  This is your, "for example" diagram that goes hand-in-hand with describing how the components in the class diagram fit together.

There are a lot of tools, both commercial and open source, for creating UML diagrams.  I found that with some initial effort I liked Visio 2010 the best.  But only after installing these invaluable, free UML 2.2 stencils for Visio.

Design Patterns
With class design and documentation under your belt you can focus on true Object Oriented techniques.  There are some resources I recommend on the subject:
  • Head First Design Patterns - is a fun way to get your feet wet with design patterns.  Some patterns are covered better than others (I don't like how they lump all of the Factory patterns together), but by the end of the book you'll understand the power of polymorphism and why we rely on aggregation over inheritance in 21st century software development.
  • The Gang of Four (GoF) Book - is the original design pattern book.  Don't be intimidated by its academic tone, it's actually pretty easy to understand.  Some of the patterns aren't heavily used and some of the examples are in SmallTalk.  Still, everyone whose job title says Software Engineer should own and have read this book.
  • For .NET developers, I really like dofactory's site on .NET Design Patterns in C# and VB.NET.  At the very least, I like how their diagrams are actual UML 2.0 instead of the GoF's proto-UML diagrams.
  • For the ubiquitous yet ethereal Model View Controller (MVC) compound design pattern, I like the MVC description on Ward Cunningham's C2 site.  If for nothing than this - The best rubric ever: "We need SMART Models, THIN Controllers, and DUMB Views"

If you adopt the techniques referenced here on a daily basis you can be sure that, even if your software doesn't live forever, you'll have less work to do in the future.  I can tell you that software I've written using these techniques (and more, such as SOA) have scaled into the millions of objects with no need for extra maintenance or rework.  And I'd rather be the kind of Software Engineer that spends my time rewriting other people's code rather than having teams of people rewriting mine.

Technorati tags: Software Engineering Software Engineering Fundamentals

Posted on Saturday, January 7, 2012 12:21 AM | Back to top

Comments on this post: Software Engineering Fundamentals

# re: Software Engineering Fundamentals
Requesting Gravatar...
I am sure that being a software engineer is not that easy because that really requires more skills and passion.
Left by air conditioners indianapolis on May 14, 2012 11:17 PM

Your comment:
 (will show your gravatar)

Copyright © John | Powered by: