A Coworker’s Response To The Future Of The Boutique Software Shop

Sean Biefeld forwarded a link to Michael Feather’s Thoughts on the Future of the Boutique Software Shop earlier today and it sparked some interesting conversations at the office, via email. One response from a coworker (Robert O’Neil, who doesn’t have a blog, as far as I know) really resonated well with me. I’m posting his entire response, with his permission, and only adding one small [Edit] near the end. Although my experience set is different from Robert’s, I share the sentiments and opinions that he offers in this response.

Robert’s Response

To me, it’s a sign of maturation of the industry.

In ‘the old days’ there were no separate disciplines – we didn’t have Business Analysts, UX Designers, Systems Analysts, etc.  Those came about because specializations became needed.  Those who did everything well gained reputations and business; those who couldn’t fell out of the industry or worked for the others.

As the scope of work grew larger, so did the teams required and no one could doing everything anymore.  As the complexity of the Domains grew, we needed analysts to dive in and really understand the issues, design the solutions, and explain them to the people doing the implementation.  As the tools became more powerful, those who implemented the designs needed to specialize more with the tools and techniques to do the best they could with them.  As software became more and more a commodity, the price of development had to fall, which required teams of experts in disparate disciplines working together more efficiently (hence Agile, RUP, etc. overtaking Waterfall).

In the early days the only interface a user had with software was the Priest of the Almighty Blue, who take a form asking for a report and return with a report at a later time.  Then came the Mini-computer, then the UNIX Workstations, then the PC and its progeny and everyone had to learn to interact with each architecture’s Operating Systems – almost all command line based.  Each piece of software, if it had a graphical interface, was different based upon design philosophies and graphical library.  The better designs and philosophies outgrew the others.

Then came Graphical interfaces (Motif, X-Windows, Mac, GEOS, and finally MS Windows) and standard interfaces became the rage.  No one wanted to learn a different way to do the same thing in different applications, so the creators of the interfaces defined ‘the way’ and no one had to think about user Interactions anymore.  Anyone who did was labeled a heretic and made to conform.

Now we’re in the age of Software as a Commodity, Software as a Service, and Web 2.0 — and user interfaces, user interactions, and work and data flow are once again important to delineate your software from your competitors. Thus the need for people who understand how to make software interfaces, interactions, and work and data flow interesting, efficient, elegant, enjoyable, transparent, and desirable.

Thus the problem isn’t that software never needed these people before, but that their need was lessened by ‘standardized’ interfaces and behaviors.  It was exacerbated when developers stopped being taught and learning the aspects of this art; this craft.  These types of people have always been with us, but their roles were reduced by the software ‘Industrial Revolution’ that relegated their input to how to best follow standards, not revise them or break them when it made sense for the product and the end-user.

I’m personally glad to see them reappear.

Rant Warning!

The biggest issue I’ve seen every step of the way in my life as a developer of software is that there are people who care about quality and those who don’t.  There are people in our industry who don’t think of what we do as a craft, of our craft as a blending of science, engineering, art, and aethstetics — and of ourselves as craftsmen.  There are people who don’t want to learn to improve what they do as much as they want to collect methods so they can hold them up as an achievement, as if the number of ways you know to do things is more important than doing them well.

Every craft has people who do it for the money and not for the love of creating something people will appreciate and enjoy.  Yet our craft, like others, continues to thrive and improve because there are people who do care.  There are people who care as they create the best software they can (or are allowed).  There are people who care as they teach how to create better software.  And there are people who care as they investigate ways to be better at creating software, ways to be more efficient and cost-effective at creating software, and ways to make software itself better.

Before I became a software developer, I worked in home construction.  I saw the same divisions there.  I saw workers who threw things together the quickest and easiest way they could; they didn’t care.  I saw workers who would do the minimum required to get their money, who would take shortcuts, and hide deficiencies.  I saw workers whose work fell into ruin within a decade.

I saw craftsmen who would tear out their work and redo it because it didn’t meet their values of quality, even though it could mean working extra hours to catch or keep up or miss a deadline.  I saw craftsmen who’d take the time to teach their juniors how to do it better.  I saw competitors discuss methodologies and techniques with each other because it improved their craft—even though they were giving away what some would consider ‘trade secrets’.  I saw craftsmen whose work stands the test of time and is still well-founded and solid to this day.

Will you be a craftsman who cares about your craft, your product, and your reputation?  Or will you be a code monkey and do the minimum asked of you to merely ‘get the job done’?

I saw builders who counted the number of homes they could produce each year as more important than the quality of those homes; they were counting the money instead of the smiles of owners happy with their new homes.  They built huge tracts of houses almost overnight.  Almost none of those builders are still in business to this day and their tract homes began to fall apart – in less than 5 years, in some cases.

I saw builders who took the time and the effort – and the money – to ensure the homes they built had a quality that ensured respect.  They hired and retained craftsmen, they acquired the best materials, they nurtured neighborhoods, and they only worked for clients who understood that craftsmanship sometimes cost more but would pay for itself.  Most of those builders are still in business today.  Their products are still viable and enjoyed by their owners – some almost 40 years later!

What kind of place will we let [insert your company name] be?  The answer to that depends upon what kind of craftsmen we are and what kind of reputation our work gains the company and ourselves.

</end rant>

I made this rant because this comment hit a chord with me:

Great piece.  This is exactly what I feel. I’ve been through the big corporate IT treadmill. In my younger days I was slapped down by senior management for throwing things round the office when people were screwing up because they just didn’t care (I’m Scottish, like Ramsay). I grew out of that to the point that I was considered an asset for my ability to keep my cool in front of provocatively stupid customers. But a bit of you dies if have to keep hiding the fact that you care, that you don’t like producing 3rd rate crap at the lowest cost.

Since I left the corporate life my enthusiasm for IT has been reborn. I’ve really been enthused by UX. That perspective is exactly what was missing from the techno-driven, “be grateful for whatever we give you” paradigm I’d grown up with. I’ve also been excited by the opportunities Agile has given for UX to be drawn into the heart of the development community, provided the UX people really want to shed their independence and get real influence at last.

It was an interesting point about most developers lacking the right “neural wiring” for UX. That’s probably historically true, but perhaps more important is that UX never really featured in the education, training or experience of developers. If they thought about it at all (unlikely) they saw it as peripheral, out there somewhere, a subjective and imprecise discipline that had no real affinity with the clear, logical, realities of software development.

Developers aren’t born knowing about all the essential disciplines surrounding the actual coding. They have to be taught the value of configuration management, release management, security & carefully designed databases.

If they are exposed to UX right from the start of their careers and if they are constantly shown how important it is to the development of high quality applications then they will get it. Maybe not many of them will be talented interaction designers, but at least they’ll avoid the crasser mistakes we all used to make. They will recognize the need to work with the UX professionals, and they will see the value in what UX can contribute to the work of the team.