Developing Software Simply

Creating software is, without question, a complicated process.  Daily, I am reminded of this fact even after 25 years in the industry.  Despite having worked in high caliber teams and with many incredibly talented programmers, none was able to produce perfect software.

I still search for ways to improve as a technical manager and when developing personal projects.  Agile Software Development is the latest high profile methodology that describes the processes and principles upon which to develop software.  After reading this interesting article on Agile and its wide-ranging comments, it seems that the jury is still out on the methodology's relative merits.  Reflecting upon my direct exposure to Agile, to varying degrees depending upon the project and my role, there are aspects of it that I appreciate:

• It provides important framework, context, and vocabulary (as, of course, does any methodology) 
• It offers a "clean slate/less-is-more" mentality that has proven to be helpful in many human endeavors (writing, music, art, etc)
• It encourages team empowerment and the flattening and distribution of decision-making

Perhaps above all, Agile emphasizes iterations.  I view this as a two-edged sword.  On the one-hand, it is a recognition of the "perfect software challenge" that we already noted.  On the other hand, it may become a self-fulfilling prophecy that limits quality.

Agile and, indeed, each software development methodology (waterfall, RAD, XP, and RUP) that I have employed -- once again, to varying degrees -- seems to provide an incremental quality uptick.  However, as many pointed out in the comments on the aforementioned Agile article, the relative success of a project remains mostly the result of the skill and experience of the team.  Another big success factor that is mostly unmentioned in software development methodologies, are stakeholder "soft skills", such as collaboration, likability, and motivational expertise.

Furthermore, Agile does not overtly call out many of the root causes of what I call unnecessary seams.  These unnecessary seams are, I believe, the source of additional complexity that we layer onto an already difficult problem.  Seams in the physical world, for example where the shoe upper is sewn to the sole, require extra work and yet typically remain the most vulnerable part of the object.

After learning the hard way, I follow these rules-of-thumb to avoid unnecessary seams:

• Avoid Multiple Overlapping Technologies  The technology in question might be a platform, language, tool, or library.  I heard recently of a project team that used both Git and CVS for source code version control.  Why?  Each of those tools is complicated enough!  Make a decision on one tool and convert the other repository!
• Don't Be Trendy  As in many spheres, humans are drawn to shiny new toys.  Although it is imperative to stay current in our very fast moving industry, we shouldn't feel compelled to always employ the latest platform, language, tool or library.  Stick to the tried and trusted!
• Buy It, Don't Build It  Balance this consideration against the previous two but, in general, use someone else's software when you can.  The benefit of using a pre-existing/pre-tested application, plugin, add-on or service will almost always be more efficient.  Don't code it yourself unless you really have to!
• Assign Appropriate Technical Arbitrator  Ensure that the most broadly knowledgeable individual on the team is the technical arbitrator.  The current trend towards "developer power" sometimes means the wrong team-member calls all the technical shots.  Think big picture when defining your technology stack!
• Recognize Automation Opportunities  Each manual step is an unnecessary seam.  Introduce automation into all of your processes, including quality assurance, builds, deployments, etc.  Automate your entire flow!
• Single Source of Truth  Ensure that you have a clearly communicated single source of truth for each of your project artifacts and data.  Too often, I see milestone dates for the same project managed in a calendar application, in a spreadsheet, and in a database.  Pick one, communicate that choice, and enforce its use!
• Make Artifacts Self-Documenting  Ensure that the names of files, properties, and other "public" project artifacts are self-documenting.  For example, if your application requires a set of 3 roles, don't name them Role 1, Role 2, and Role 3.  Instead, name them something like Administrator, Project Manager, and Developer.  There will be many occasions when stakeholders will need to refer to these roles.  Don't require your stakeholders to perform mental mapping!
• Keep Teams Lean  It is tempting to believe that additional personnel and further specialization on a project will always result in a net gain in productivity.  This has been largely debunked in favor of right-sizing the team to eliminate unnecessary lines of communication, to reduce the consensus building effort, and for more direct ownership (see my previous blog post for more details).  Reduce the number of stakeholders to a minimum!
• Inspire Ownership  Enthusiasm and pride for a product (or project) is mostly the result of a stakeholder's perception of his or her ownership.  The product's quality typically parallels the team's collective enthusiasm.  The signatures of each of the vaunted Apple Mac team were included on the interior of the initial 128K Macintosh case because "artists sign their work".  Encourage creativity with software Easter eggs and the like!