“You are getting the BETA version of our seed funding”

So Google is now seed funding widget/gadget creators through “grants”.  This is making interesting news in the headlines and I don’t need to talk about it here because it is/will be all over the blogosphere.  However, the one thing that caught my eye is that the funding program is in “BETA”.  The logo on the Google Gadget Ventures site has the customary Google “BETA” on it.  Is BETA the new word that they are using for “…a new Google pilot program dedicated …”.  Or does it mean that gadget creators will be getting the BETA version of the funding. If so, why would one want BETA not Version 1.0? When does the usage of this word become overkill?  It’s over usage (and unusually long periods of BETA state) is beginning to take its toll on its value, if it has not already. Right now I am really hard at work trying to make the decision whether we will use the word “beta” to identify any of our version releases. I doubt that we will perpetuate any further usage of this word.

“simplicity of solution” is an essential element of quality

Last month, I posted a response to Brad Feld’s question, “Why Do Computers Suck So Much?”, which I think deserves its own posting here because I feel so strongly about it:

Computers do not suck so much, it’s the software engineers. Software engineers suck even more. Being a software engineer myself, I think over the years the quality of engineering in software has been slowly going downhill and it has been no secret. While I know some of the reasons why software is sometimes deliberately designed so that is difficult to use with certain third party products (forced migration strategy anyone??), I would like to take your question as an opportunity rant on my dissatisfaction with the quality of software design and engineering in general. It’s just something that has been irking me for some time.

Software engineers tend to forget that software engineering is a craft. It’s a craft whose beauty is in the detailed attention paid to the relevance of the functionality and the quality of the finished product. Engineers tend to forget this fact and their managers tend to be ignorant of it. Engineering managers have been lacking in identifying great engineers. More often than not, engineering managers do not understand the composition dynamics of a great software engineering team. Most managers mistake the person who can whip up the code the fastest (and rant differences between technologies and languages) to be a great engineer and they stack their teams with a whole lot of those types of engineers. A great engineer is a person, who can not only find smart solutions to complex problems but one who can also simplify the solutions to complex problems. The smartest guy in the room is not necessarily a great engineer but just a smart guy. In my working with some of the engineers and their “program/product managers” from some of the “tier one” software companies, I noticed that a lot of them were simply just smart guys and not necessarily great engineers because they failed to make abstractions of software that were any less than “smart abstractions”. (The average user is better served not by smart abstraction of software but rather by simplified abstractions.) The end result is software that just does not “simply work” as the average user would expect. Instead, users must know that this and that needs to be done before they can complete their tasks because to a geek engineer, his/her tester and their program/product manager, that is “so obvious”. What they fail to understand is that users have an affinity towards simple abstractions as evidenced by the fact that when all else fails, the user falls back on the simplest abstraction of all “turning it off and turning it back on”.

I have not been around long enough to say software is not longer being developed the way it used be, but I have been around long enough to know that software is neither being designed not engineered the way it should be. Software engineers, who view their work as a craft, should view “simplicity of solution” as an essential element of quality of their work.

Getting Real – the forgotten chapter

After listening to an agile software development presentation at Rally Software that included excerpts from the book du jour for web 2.0 developers today, “Getting Real” by 37 Signals, I went back to a thought that I had after I read the book several months ago. While digesting all the information that I had read, I realized that “Getting Real” offers a great template for agile web app developers; however, it also puts a lot of responsibility on the software developer above and beyond what has been traditionally expected of developers. After reading the book , you realize that a develop is no longer a person who possesses code cranking skills only but a person with a conglomeration of skills in order to satisfy the principles in “Getting Real”.

What skill will I be looking for in our next hire person for our web 2.0 which follows the “Getting Real” agile software development model? As a former, software architect, I identified that the closest skills for a person that fits the bill are that of a software architect (in addition to the developer skills, of course). Now, I am not trying to turn the whole “Getting Real” on its head and introduce the role of an architect, I am merely saying that the skill that should be innate (or trained) in person who can successfully thrive in a startup company implementing the “Getting Real” principles is commensurate with the skill that is required of a software architect.

In addition to suggestions in Chapter 8 of the book, I would hire a person who possesses the following skills that are often associated with software architects:

Constant understanding of a system’s organizational structure

Since we have no req specs with “Getting Real”, the developer must constantly keep in mind the overall view of the system as well as its constituent functional components and their relationships. This goes a long way in cranking out code faster because one must constantly understand how changes affect other parts of the system.

Ability to curb unbounded complexity

It takes a certain level of skill to deliver software that provides value, is simple to use and is powered by a non-complex system. Simply saying ’no’ to feature requests does not necessarily equate to a less complex system.

Leadership

The ability to influence and inspire, is a quality that is continually evident in the 37 Signals guys themselves. “Getting Real” principles result in a product that is characterized by an impassioned boldness of the product and the people; and leadership is definitely an essential quality in achieving both.

Effective communication

A developer that successfully follows these principles outlined in the book must be able to communicate on three axis: X-axis - horizontal communication with the other members of the team, Y-axis - communicate with the your startup management, board, advisors, investors and any other developers under him/her , Z-axis – communicate with the product users. “Getting Real” emphasizes the importance of engaging with your users, this will yield the best results if your developers have effective communication skills.

Understand and appreciate business strategy

In order to “hire the right customers”, “have an enemy” or “underdo your competition”, a developer must understand the business strategy.

Political Skills

While traditional software architects must possess the skill for political navigation through an organization while championing the product, I think the political skill required here is a little different. A developer must be able to identify when politics start to affect the product in ways that are not in the best interest of the product and put a stop to it. Even small startup teams such as those suggested by “Getting Real” have a certain level of political dynamics not only within the team itself but also among other entities that interface with the team such as investors, advisors etc.

In addition to the “Staffing” recommendation in the book, I will definitely be using all the above-mentioned to evaluate our next hire because developers just cannot afford to be simple code crankers anymore.