Evolution of Software Engineering

The actual coding of software is really just one small piece in a much the larger fabric of delivering bona fide functional value to users. Here at Edmunds, on the eve of the full site launch of our redesigned site (two years in the making), we find ourselves in the new.

New infrastructure, new processes, new tools, new ways of working with each other and new ways of thinking about ourselves, i.e., how do we as technologists (or for that matter as individuals) provide optimal value in an organization that has organically, seemingly overnight, evolved to place where nearly everything that has successfully brought us where we're at is being turned on its head? The roles that we've played and hung our collective hats on are, for the first time, being significantly redefined in the pursuit of innovation: to break out of the practice of doing relatively small, incremental improvements and into producing something truly different.

The general ethos of the Edmunds team has come to re-conceptualize "software development" to be the broader end-to-end process cycle of delivering value to the user: from idea creation (what to build & why) to production deployment (what, when, who and how often). What this holistic view ultimately means is that Software Development = Product Development. So as the organization starts a new chapter with the adoption of Design Thinking, it feels surprisingly comfortable alongside concepts established (or at least in the process of being established) such as Agile software development, Dev Ops, and Test-driven development (TDD), Scrum, and Kanban swarming. In fact, in a way, it's feels like the natural evolution of these practices. It feels comfortable because unbeknown to ourselves, we've evolved.  

So I find myself asking, if software has no value until it's in the hands of real people (users), then what are the things that stand between the idea and effective instantiation of that idea? The answer to the question, and following the question to its natural conclusion (what should be done about it?), is a set of even newer infrastructure and newer process and newer tools. Moreover, it involves yet further redefinition of roles that have to be first broken before they are truly remade. Reevaluating the tasks and responsibilities of roles like "software engineer", "QA engineer" or "release manager" is just the start. A deeper look will naturally lead to questioning some of the principles that have historically been sacrosanct: the requisite checks & balances between Dev & QA, governance of what gets approved (or not) for a release, the concepts of what is a "release", the ceremony around actually pushing functionality to production. Many of these conventions exist to stabilize an inherently dysfunctional system. A system where developers hack out code with little regard for building quality into their code; a system inflexible and so prone to errors that it must be tightly and painfully gated to ensure adequate quality.  

But what happens when an organization has sufficiently evolved beyond this?

Stay tuned and find out.