The Technology Executive and the Software Craftsman

Back in the Day

As a technology executive, I’ve been around software development for over three decades. Those who entered the development workforce as developers in the 1980’s as I did were typically educated as and thought of ourselves as software engineers. We were taught structured methodologies of the day based upon the writings of notables like Yourdon, Ward, and Mellor. We were drilled in development techniques including data hiding and encapsulation focusing on the disciplined used of data structures and algorithms with the aim of making our software more flexible and maintainable. The development tools of the day consisted of compilers, assemblers, linkers, and loaders and little else. Often, we were not only developing software but we were simultaneously developing better tools to help us develop that software. Simply put, we were not only developing software products but were also developing the tools to fill the gaps in the tool sets of the time. In spite of these hindrances, we managed to produce fairly robust code.

Using these methods and tools, we were often employed in medium to large scale projects using traditional waterfall project models which valued rigorous documentation to communicate requirements, design, architecture, code structure, and test cases. Those of us who worked on military projects were exposed to such software development standards as DOD-STD-1679A and DOD-STD-2167. I was involved in military, medical, and financial software projects. In spite of our best intentions to “engineer” software following the models and standards of the day, many projects were delivered late, only partially met the requirements, and were fairly bug-laden. As software engineers, we intuitively knew that something was fundamentally flawed with our methods and that developing great software was more iterative than we were taught. However we often felt at a loss to know how to change things. We knew that close collaboration with our clients and subject matter experts often yielded better results since we could better understand user needs through such collaboration, but the waterfall process created barriers to collaboration in deference to formal documentation and methods.

A New Breed

In the intervening years, I have seen development tools mature to a point where they enable better productivity through means of integrated visual IDEs, real-time code analysis, and automated unit testing tools. The tools not only enable developers to manipulate code and resources better but often do tedious tasks automatically and offer helpful guidance to produce better code. In fact, many recent tools support the ongoing refactoring of code to ensure quality and maintainability as the features and functions of the software evolve over time. This helps reduce the entropy that often seeps into software products making them bloated and unwieldy to maintain over time. In short, the tools have evolved to not only reduce the friction between developer and code but have become an ally in producing high quality code faster. In addition, more iterative development methodologies arose as development teams realized that tight collaboration with the customer was a key project success factor. Today, the various flavors of Agile (with a capital “A”) development are the de facto standards for most software development since it acknowledges the inherently iterative process needed to develop great products that are better suited to the business needs.

As the development tools have reduced the friction between developer and their code and Agile development methodologies brought developer and customer into tighter collaboration, I have seen a change in the ethos of developers. Under the guidance of technical experts and mentors like Robert Martin (aka Uncle Bob) and others, developers are trained, or maybe more accurately indoctrinated, in a new way of thinking about software development which focuses on the delivery of well-crafted, high-quality code. This goes well beyond traditional training in techniques and methodologies to a level of almost Zen-like devotion to fitness and quality. Having read some of the materials by modern day software gurus like Uncle Bob, I have found a theme where some developers see technology executives as a hindrance to the crafting of great software. This is almost a “we’ll build great software in spite of the obstacles placed before us by our managers” feel to the discourse. Developers are now challenging and entreating the business to support them in building the best products possible because they care about their craft to which they put their name! This new breed refers to themselves as “software craftsman” and with good reason. As craftsman, they understand that software is only partially engineered. They understand that truly great software development is an organic mix of close collaboration with their customers to guide the application of the technology and tools. In short, this is what many developers from “back in the day” intuitively understood but could not instantiate into real solutions for software development shortcomings of the day. It has been and continues to be my privilege to work with these craftsmen. I find myself in admiration of their dedication as I reflect on the earlier days of software development.

Vendors versus Partners

So as the developer ethos has changed and evolved into that of the software craftsman, the mindset of the technology executive must also evolve to better leverage the ethos and skills of their software craftsmen. A former executive colleague had a saying, “Squeeze a Vendor, Hug a Partner.” All too often, technology executives see their development staff almost as vendors whom they engage to produce a product. I must say that I have been guilty of the same outlook. Treating developers like vendors often means that developers are given the requirements and access to subject matter experts and then set loose to come up with a solution. The technology executive then monitors progress and squeezes the vendor to deliver the product as efficiently as possible. In short, “squeezing” vendor relationships often lack trust and that shows through to the software development “vendor.” All too often, the technology executive is left disappointed as the solution falls short in features, quality, or delivery timelines. Based upon my own experience, there were two simple reasons for this. First, the technology executive was squeezing the development staff to hit a timeline without arming the development staff to make the right tradeoffs needed to deliver quality software. Second, the developers did not understand the full context of the solution they were asked to develop including such things as market forces at work, sale pipeline pressures, the competitive landscape, and any other number of factors influencing the making of good business decisions. Like a vendor, they were only told as much as the technology executive thought they needed to know. Based upon the information available, the developers did the best they could.

Now let’s contrast this to a partner relationship. Partnerships are based upon the alignment of intentions and motivations between parties. Partners share the full vision of the goals to be attained with the hope that they can arrive at mutually beneficial solutions. Partnerships are based upon trust that each party has the others back and that success will be achieved through the mutual nurturing of the partnership. Partnerships aspire to add value to both parties in a “rising tide lifts all boats” ethic. Partner relationships are for the long term while vendor relationships last for the duration of the product delivery.

Believe it or not, technology executives and software craftsmen share the same intentions. They both want the best product possible, they both care deeply about the fitness of the solution to meet the customer need, they both want a sustainable high quality outcome, and they both want to avoid putting their name on a poor outcome. In short, when the technology executive and software craftsman come together as partners, they find that they want the same thing!

A Call to Action

So how can a better partnerships between technology executives and software craftsmen be forged? It’s really quite simple and can be explained in two words: Communication and Trust.

The technology executive needs to arm the software craftsman with the information required to make the best decisions possible based upon the true business need. Simply communicating requirements is insufficient. The technology executive needs to engage the software craftsman in a continuous and ongoing dialog about the business including a transparent discussion of the opportunities and challenges facing the business. I think you will find that the your software craftsman will eagerly absorb and digest this information and use it to design and develop better solutions that transcend the boundaries of the requirements to make their solutions more fit for a broader business scope. I hold periodic meetings, usually over lunch, where I brief the senior technical staff on the state of the business and how their solutions fit in. We have spirited discussions and action items resulting in improved development methodologies, tooling, and product features to help achieve superior results. This has been like a bit like letting the genie out of the bottle. With a little effort and trust, software craftsman can produce magical results!

The software craftsmen need to make their executive partners understand that they care deeply for their craft and demonstrate that they are aligned with the goals of the business. The technical staff needs to understand that it’s healthy to challenge the business and bring executives to the notion that it is not only a good idea to include the technical staff in the business dialog but it’s essential to the development of the best possible products!

Only through a true partnership between executive and craftsman can superior results be achieved. As a result you’ll get side benefits in return: a new sense of trust and satisfaction. Aren’t those at the heart of what both technology executives and software craftsmen desire?