"Source Code" should not be "The Source" in 2013!

"Source Code" should not be the Source of an Enterprise Application's Infrastructure in 2013!

Instead, the infrastructure should be described abstractly, and then an ESCIM (Enterprise Source Code Infrastructure Management System) should maintain the application's infrastructural code.

This frees up software developers to focus on the "exceptional" cases.  The interesting cases.  The cases that provide an opportunity for creativity.  Cases that deviate from the established system architecture.

In other words - anything that can be automated, should be automated.  Let people do what people do best - be creative within an established system!   Or, easily and creatively manage/change the established system to make it better.

Developers are still slaves to infrastructure.  It does not have to be this way!

Software Design/Modification Should be considered a "Set Based" process

When Matt Cherwin, the skilled DBA at my company first joined, one of the first and best pieces of advice that he gave me was to think of SQL as a "Set Based" process.  In other words, something in our discussion had indicated that I was thinking about the specific rows in a table, and his advice was given in response to that observation.

Immediately - SQL became much "easier" to think about, manage and generally work with.

I have found that this advice also applies to software development.  I find that it is much more powerful to think about the entire system (as a set) and to think about changes to the entire system (set).  This heavily takes advantage of code refactoring - where essentially every single last change that is made to the code is done as a formal "refactor".

In other words, I'm going to refactor the code to...

• Rename the method x.Foo() to x.Bar();
• Add method X to Y in order to facilitate Z.
• Add 5 new properties to class Foo.
• Allow Bar's to be deleted.
• Create 3 overloaded version of method X.Foo() that allow for...

The point is that any one of these changes might modify 1 line, or 10,000.  It should not matter to me as the one implementing the change.  I need to understand the implications of the code change - but I should not need to actually eyeball each change made by "the system".  

I should be able to simply indicate what I want done - and a refactoring tool should actually make the changes to the code.  The more changes that can be made "as a set", the fewer bugs there will be in the final product.

Define "Set Operation": Any operation that can be completed as a single, atomic change in the IDE.

Find a cheap way to try!

I've spent a lot of time thinking about failure, and how the fear of failure so frequently prevents people from trying things.  Weeks or months can be spent debating the various ways that an idea might fail when a prototype could potentially be developed in days that would answer the question conclusively.

I recently watched a TED talk by Regina Dugan from DARPA - with a message about the amazing things that we can accomplish when we stop fearing failure.  One of the things that she kept mentioning, and it wasn't until this morning that I realized how important it was, was how little was known before a test, and how much additional knowledge was gained by trying - even when the attempt results in failure.

For example, when Chuck Yeager made the first Mach 1 flight - Mach 0.8 was apparently the best wind tunnel data available at that point.  Leaving the sheer courage necessary to climb into that cockpit aside for the moment, because he tried - they learned more about supersonic flight that day than in all of the previous testing/theoretical work that had been done up to that point ... combined.  

In example after example, she kept coming back to how much they learned the first time that they tried to fly Mach 20, or from the first prototype mechanical humming bird that they built (even though it only flew for seconds).  Trying, even if it results in what appears to be complete and total failure, almost always yields so much additional information about the problem being attempted, that failure can simply be categorized as an irrelevant side effect of the learning process.  Failing 10 times is fine with me, if those 10 failures lead to success - which lasts forever.

Setup the Playground 1st!

Before starting any development project, start by envisioning the perfect environment in which you want to develop said project.  If this environment does not exist, start by creating it - then move on to the project at hand.  Any services, features, helper methods/functions that can be handled abstractly by the environment should be considered 1st.  Only after "the playground" infrastructure has been setup - then move onto the actual project at hand.

The interesting thing about this process is that it is completely recursive, from a large - think operating system scale project - all the way down to an individual line of code.  Literally (as in, the literal definition of literally - not the figurative one!)

In other words, you're going to develop an operating system.  This system will need a file system, memory management, process management, thread management, etc. ... eventually.  But to begin with, whichever of these features are implemented, all operating systems need a bootstrap module.  You (definitionally) can not have an operating system without a bootstrapping function.

So, let's start by designing the much smaller concept of a simple kernel.  Not the final, full OS level kernel - but just the smallest kernel that I can think of.  i.e. If we were given 12 hours to write an OS - could we develop a kernel that could bootstrap a piece of hardware to some sort of "operational" state in 12 hours?  Even though I've never done anything even remotely like this before, I think that with the appropriate training, I could create a kernel in 12 hours.

In fact, there are probably 5 or 6 different ways that a "kernel" could be written.  This is where the creative/editing/design process really kicks into gear.  Because, now (hopefully as just a thought experiment at this point), each of the different approaches can be considered, in the larger context of the 6 months full OS development project that we're actually working on.  Most likely 1 or 2 of these models will show a substantial benefit over the others.

These 2 now become "finalists" as the potential model for our kernel.  At this point, it probably makes the most sense to just pick one and give it a try.  Within the first 3 hours, we hopefully have something productive.  In fact, we probably have enough to be able to really (in depth) re-evaluate our direction, and make sure that our assumption about the two finalists was accurate.  Often at this point in the process, it becomes absolutely apparent that the other approach (or possibly, even one of the 3 that was originally discarded) is actually a much better way to solve this problem.

The key to note at this point in the process is that it's REALLY cheap to switch completely the design at hand.

If we take the full 12 hours before we re-evaluate we're already pretty "locked in" to the design that we started out with.  Be open to change.  Be ready for the fact that many to most of the decisions that you make might be wrong (fail!).  But if you're open to that idea, you're much more likely to recognize the failure, and change course, early!

Axioms, Limitations and Freedom of Thinking

Axioms, Limitations and Freedom of Thinking

Argue for your limitations, and sure enough, they're your's.

-- Richard Bach, Illusions

Where do ideas come from?

That is a harder question to answer than this one:

What prevents ideas from coming?

What I think prevents creative, outside the box thinking, is in most cases arguments for limitation.  In other words, one is never going to break free of "the box", if step one is arguing that there's an unbreakable, cubic shell surrounding your idea!  If you start by coming up with all the reasons that you can't get outside the box, it's unlikely that you're going to find a path out (even if one exists right under your nose).

I've spent many years thinking about this quote, and I think that today, for possibly the first time, I may have begun to understand why arguments for limitations are so costly.

I would contend, that what we "know" is always based on axioms.  Unfortunately, "thinking outside the box" often involves changing ideas that were originally considered to be axiomatic.

When arguing for your limitations, things usually unfold as follows:

Dave: "I want to go skydiving, but I hear you only fall 125 MPH - I want to fall faster.  How can I do this?"
Bob:   "Sorry Sir, it simply can't be done."
Bob:   (often unspoken) "...Because that's how terminal velocity works, and unless you're going to gain 50 lbs, you're just not going to go any faster than that.  Sorry."
Dave: Ya know, I think you might be right.  Oh well.

By starting with a claim of impossibility (before the discussion has even begun), Bob has now (usually inadvertently) hardened as AXIOMATIC the reasons that it can't be one.  What if one of these assumptions (axioms) proves to be either completely, or even just partially wrong?  What if the outside the box idea, requires changing one of these ideas that are held as sacred?

Rather than starting by arguing for your limitations, consider this discussion:

Dave: "How can we accomplish Project XYZ?"
Bob:   "Well sir, that seems tricky.  It appears that for this to happen, A would have to change fairly substantially.  Hmm, B also, does not seem like a viable option.  Although... ya know, if we swapped D and E, then we could remove C altogether and that would solve the problem!  Hazah!"
Dave: "Fantastic - when can we get started?"

The point is, that if Bob starts out by stating the obvious - that it can't be done, he has already taken the "outside the box" idea that D and E could be swapped off the table.  Because for his original statement to hold true (and everyone always wants to be "right"), then D and E CAN'T switch places, so why on earth would he even think about it?

Notice that bob started at A, and first ensured that A and B were not viable solutions.  Only then did he consider the better solution.

Always be open to any idea being "wrong".  That way, you won't miss the really good ideas when they're staring you right in the face.

Writing code is like a mediation/negotiation

There seem to always be two sides of a story when writing code, and to some extent, the process of finding "the right" code, or the most elegant solution ends up proceeding as follows:

I just allow the code to essentially battle itself, with me as the programmer acting as the mediator in the negotiation.

So, the negotiation typically starts with the calling system asking attempting to call a function on the responding system that does not originally exist.  Consider this an "opening offer" where the calling system provides as much (or as little) detail as IT thinks is necessary for the responding system to answer the question or request.

This will generate a matching method in the responding system.  Now, we try to respond to the calling system's request, specifically from the perspective of the responding system.  Hopefully, the information provided is sufficient and an answer can simply be provided.

In many cases though - the responding system will need more information - so it should "request" this additional information by adding a parameter to it's function signature.  This will generate an error in the calling system's code.

By switching back to the calling system's perspective, providing the additional parameter is usually possible. But if it is not directly possible, either the calling system needs to go get the relevant information, or provide the next best option available.

By switching back to the responding system now, maybe the alternate information provided actually works, or may cause the responding system to change it's usage again.

This process continues until a  mutually agreeable set of code is found.

An important note about this process is that at the point that the original "opening offer"  was presented, a final solution to the problem was NOT completely understood.  This process is the method to FIND the solution.  It is NOT presumed that the solution is known at the beginning of this process.