The software industry has a long history of recreating incompatible solutions to problems that are already solved  Pattern Oriented Software Architecture Volume 2

 

In 2001, my good friend Barry Varga  and I co-founded this company for a variety of reasons.  One of those reasons was to make decisions for our own company as previously we had worked for a variety of other companies where we watched the people in charge make, well, lets just say questionable decisions.  We felt that we could make better decisions or at least, we would be accountable for our own decisions we thought how, could we do worse?  I am sure this is how MiniMicrosoft kinda feels.

 

One of those decisions directly affected our programming team, which was, dont write code at least initially.  It sounds strange as most programmers (read: all) love to write code including yours truly.  The issue is that designs precede code and requirements precede design.  Pretty fundamental one would think.  However, as programmers, we are all guilty (and still are) of not conforming to this basic tenet.  Oh to be sure, there are a whole pile of reasons behind this we are good at rationalizing that we dont have any requirements or market intelligence to tell us what to code.  We also have great imaginations and think we know what the customer wants.  We also believe that regardless of size, complexity and/or change, by coding first we can figure it out

 

Since we were writing code on the MSFT platform, and have been since VB1, we knew, as old school programmers that it all has been done before, you just have to find an example.  The World Wide Wasteland has many examples of whatever you are coding.  In fact, since some 50% of the 8 million programmers out there code on the MSFT platform, you are bound to find an example or ten (or hundreds!) that is pretty close to what you need for your component/project/product.  Of course, the cynical programmer and/or perfectionist programmer type (arent we all?) will want to write their own code because what they write will be better than whatever can be found on the internet- surely.  Sometimes this is true, but in most cases not, or a least in my 15 years experience in the field.  This is also sometimes called the Not Invented Here (NIH) syndrome.  This is one of the major barriers to reusing perfectly good code that already exists. Oh, did I mention that coding is fun?

 

We also got our teams to think of different ways to solve various problems (once we had some semblance of requirements to iterate on).  In other words, come up with a design first.  Then think of 3 ways to solve the design, including searching the internet to see how other people have solved similar problems.  Then present those findings in an objective manner.  Once people thought this way, we were able to leverage and reuse several pieces of existing code (and design patterns) to solve a much bigger puzzle.  This meant that we could solve the problem in a much more timely and realistic manner.

 

The key word being realistic.  Anyone that has been writing code for any number of years knows how hard it is to write code from scratch to solve problems of any real size or complexity.  Not only is it really hard work, but the amount of effort required sometimes seems insurmountable.  We do have best practice processes and tools that raise the level of abstraction, but it is still at such a low level it still sometime feels like assembly language programming (to me anyways).  Also, when you the programmer, are the owner of your own software shop, you get a bit concerned as to how much time and effort is required to solve various problems particularly when you know they have been solved before (many times!).  Here is where refactoring really helps find any way to get the problem solved, like right now (hopefully by reusing some already existing code) and we will come back (given time) to refactor the code to make the design better.

 

Why am I saying this?  I see programmers everyday still re-inventing the wheel or NIH or doing everything else but trying to reuse and leverage some chunk of code, component, design that has already been designed, tested and reused by many to solve the same problem.  I ponder the reasons to why that it is while I have mentioned a few in this article, it still amazes me.  Even seasoned pros fall into the trap.  Maybe it is just too easy?  Maybe it is a combination of a whole pile of things.  Maybe it is simply that our software industry still has not gone through the industrialization (i.e. maturity) process like other similar engineering industriesWhatever it is, next time you open your favorite code editor stop!  Ask yourself this question did I look on the internet to see that this problem has been solved before?  If not, ask yourself why maybe you have the answer.