Concepts of Software Engineering

I was (am) listening to the Alt.Net podcasts today.  I just came across this podcast series last night.  I don't know why I didn't hear of this before, but perhaps it's because it's relatively new as it's only been publishing for a few months and is up to 8 episodes.

At the same time, I'm on a three hour train ride from Baltimore up to Connecticut to talk to a potential new client (to be specific, an interview).  The combination of brushing up on some things I don't do on a daily basis in case I'm asked about them, as well as some concepts discussed in this broadcast has brought me around to something that's on my mind relatively often but that I've never written down...

What are the key concepts in software engineering, as of today, in July 2008?  This is not meant to be an complete list, or that the items exhibit complete separation of concerns relative to each other.

Here my initial stab at what I think are the things you must exhibit to be an exceptional architect at this time:
  • Domain Driven Design (DDD)
  • Test Driven Design (TDD)
  • Software Evolution / Continuous Improvement
  • Patterns, Patterns, Patterns
  • Dependency Injection and Inversion of Control
  • Policy based programming
  • Aspect Oriented Programming
  • Doing things as much in a declarative nature as possible
  • Domain Specific Languages
  • Separation of concerns
  • Design by contract / Interfaces
  • Service Orientation
  • Transparent translation of domain to persistent store
  • Mocking
  • Parallelism
  • Caching
  • Factories
  • POCO 
  • Event Driven Design
  • Orchestration
  • Rules
  • Logging / Instrumentation
  • RDBMS design
  • Keep it simple stupid
I'm going to come back and expand this list as well as elaborate on each.

Why should I hire you?

I was thinking about this question today.  I came up with this answer.  Probably better for a tweet, but I thought I'd write it here anyway:

I Love to learn, create, and through those provide services that allow others to exceed their goals

FoP, Maintainability, TDD, Patterns, and the Process of Creating

In FoP, Karl states that your goal is to create highly maintainable code.  His thesis has many presecriptions for this, but I wanted to make a few comments about what I consider the process of creating.

I program computers because I like to create.  I like to "design" new things, and make them reality.  Basically, I like to take things that already exist, and apply the things that I have learned to make them do new things.  To be technical, as "Herbert Simon" would say in "The Sciences of the Artificial", what I do in designing things is apply knowledge to transform something into something else; I create through the process of design, which is an artifical process because it uses cognition instead of being naturally occurring.

Now, this creating can be done done several ways.  One is to modify something that already exists to do something differently.  Another is to take two or more things that already exist, and combine them together with some new stuff to make them work together to do something new.  Or you can just create something altogether new.

Regardless of which of these scenarios, the end result is something that I want to be proud of.  And I like Karl's statement that your goal as a programmer should be to make highly maintainable code, and I think this is spot on.  That is how a programmer has his achievment most accurately measured.

Why?

Because showing that I created something new, and did it well, is what gives me the most satisfaction.  Highly maintanable code means that the code can be understood, that it follows patterns of practice that have been gained through my experiences, and probably most importantly that because of both of these the people using it can learn to do the same if not better.

But what is meant by "highly maintainable code"?

I think this breaks down to several things:

  1. The code is built using patterns of practice that are easily understandable so that it can be "maintained" - that is understood completely by others,
  2. The code is tested and proven to do what it is intended to do, otherwhise it is surely not "maintainable".

I used to be skeptical of TDD.  I now embrace it wholly.  I used to wonder why I made this change.  And I quess that is why I was so perturbed in a previous post when I mentioned that I was actively prevented from building a test.  After all, without being able to create the test and prove what you did, how can you tell if you created something effectively?  And what better a way of defining the measurement of your quality at the start so that you can guide your way to your goal?

 

About the author

I'm a .NET, XAML, and iOS polyglot that loves playing with new things and making cool and innovative stuff.  I am also a Mac junkie.

I am Principal Technologist for SunGard Global Services in NYC, in their Advanced Technologies practice, and I work extensively with SunGard's energy and financial customers.

Note the the posting on this blog are my own and do not represent the position, strategies or opinions of SGS.

Widget TwitterFeed not found.

The file '/widgets/TwitterFeed/widget.ascx' does not exist.X

Recent Comments

None

Month List