User-Centric Development Revisited
A little over a year ago, I opined that in writing code in service of our users, we as developers should spend our time bettering the tools that build on the platforms that our users are using. I was speaking mostly about web development, and it’s a given that code – standards, libraries, frameworks – on the web evolve extremely quickly.
I just read a post from someone, with what sounds like a Java background, lament that modern developers approach their work more as assemblymen than craftsmen. That is, it’s easy for us download a few best-of-class frameworks, point the APIs at each other and build applications that serve some business need. When we get stuck on some piece of the module’s internal logic, we tend to leverage forums and mailing lists first as opposed to getting our hands dirty with debuggers and stack traces.
I dispute the characterization of a modern developer who doesn’t run a debugger, but there’s some validity to the first point: a lot of open source frameworks are available for all layers of the software stack and a lot of the resulting complexity comes from the various interactions between these tools. Of course, we’ve evolved to this model as the amount of code and the progression of technology itself is increasing, with heightened user expectations driving the speed and efficiency of development.
This is how much more important the user factors into software. There’s been such an increased emphasis on user experience, on user research and feedback, on iteration of features and APIs and codebases. Our current engineering philosophy puts more weight on coding to solve a problem, and at the same time sacrificing some depth in fully understanding the code we produce. It’s a sustainable methodology as long as off-the-shelf modules are flexible enough to satisfy your product requirements and your user’s expectations.
The flip side is that once the code grows beyond the capabilities of the initial set of frameworks and abstractions, there will have to be a custom solution and those engineers will have an in-depth understanding of the technology at its basic level. The main difference between two decades ago and now is that instead of building proprietary code locked inside a corporate repository, these new frameworks are themselves open-sourced and shared to another generation of developers. Google Closure, Backbone, Hiphop, Ruby on Rails, etc. – are systems that have greatly enabled a multitude of other engineers and companies.