Groundhog Day

It dawned on me that in most enterprise, at least those that I have worked in, and I have worked in MNCs of all sizes and nationalities, that managers of software development teams do not understand our craft.

Too often they look at it from a operational perspective. That is the "project" has to be able to be delivered on time, scope and budget (yeah right) and that the team is to be managed by pushing the right buttons and creating the right processes.

This is the wrong way.

If managed properly, software is about solving problems. If you are a software developer and you are continually solving the same problems, then your application and the development team has room to improve. A simple example would be a piece of code that does the same, or similar, function in two places. Generalize and put that into a library.

Software done right should be like innovation, you're always solving the new problems, or old problems in new situations, but never old problems in the same situation.

In short, you should never have to do the same thing twice.

The Goal

Why am I starting this blog?

I am a computer engineering graduate and a career software developer. I am also an MBA student.

It all started with the book "The Goal" by Eliyahu Goldratt, which introduces the Theory of Constraints.

This blog is on my thoughts on software developer, particularly on gaining a deeper understanding of creating software from a non-technical perspective; from management, processes and achieving excellence in our craft for a holistic perspective.