Hacker | Engineer

During our weekly team meeting yesterday, it occurred to me that many development teams could benefit from rotating developers through specific roles on a regular schedule. Bugs need to be fixed, but making one team member shoulder more of the bugfix burden is not healthy. Likewise, building new features instead of re-factoring old ones can be great fun, but everybody needs to share in the ups as well as the downs.

I’ve worked at places where the bug report list is so long nobody thinks we can ever get through it all. As such, it ends up being this intimidating mass of yuck that we all deliberately ignore, and bugs go unfixed. Since no member of the engineering team was specifically responsible, nobody did anything. I think a far more effective system would be to put the responsibility for fixing bugs on a single individual, but that’s not going to last very long. Therefore, I propose rotating bugfix duty every week, but every week somebody is responsible for only one thing: fixing bugs. With a system like that in place, I think you could get to zero major bugs fairly quickly, and then start tackling somewhat more fun user requests and such that come in through the ticketing system.

Other developers may disagree, but I find building new features by far the most fun and exciting part of software development. If I had my way, I’d just spend all my time building new features instead of updating old ones or ensuring consistency in the interface. When you’re adding features, you’re creating something from nothing. That’s cool. Every developer should get his or her chance in the sun, a time to dig in and build some cool stuff. Rather than sneaking features in between fixes and infrastructure work, feature-building time should be concentrated and rotated between developers, much like bug fixing. I’m not sure what the interval should be, but probably longer than a week. Of course, some features require far more work than one developer can do in a couple of weeks, but there are generally plenty of small features in the queue to work on.

User advocacy is critical to a well-functioning software development team. No matter who is doing it, somebody needs to be thinking like a user, talking to users, and generally immersing him or herself in how the users use the software and what their needs are. Too often this work is pushed off to non-technical, even management people, without giving developers a chance to connect directly with users. Sure, many of us are a bit rough around the edges (some are downright antisocial), but I believe communicating with users can be a growth experience for every developer. Rather than pushing user advocacy off to somebody else, let a developer do it for a week!

Behind everything is the infrastructure work: refactoring, optimizing performance, building out architecture, and maintaining software all fall under this umbrella. I think there is a wide variety of developer attitudes toward infrastructure, but much like the other three areas it should be rotated through the team. Some developers call themselves “backend” or “frontend” engineers, but really everybody should have a picture of how the whole system is put together. Without a common vision (including the infrastructure), how can you move forward efficiently?

Feature creation, bug fixing, user advocacy, and infrastructure work are all critical pieces of a functioning software development team. By asking developers to concentrate on one specific area at a time and rotating all developers through the focus areas, I believe a team can be better integrated. In the end, a well-integrated, efficient team can get the job done cheaper, better, and faster.

Hacker: A person who enjoys exploring the details of programmable systems and how to stretch their capabilities, as opposed to most users, who prefer to learn only the minimum necessary. – The Jargon File

Engineer: A person who uses scientific knowledge to solve practical problems. – Princeton WordNet

I have found myself straddling two worlds for some time now: that of the Hacker and that of the Engineer. When I started writing software back in the late nineties, I was very much a hacker. My interest in writing software came out of my constant obsession with tweaking my computer and breaking the systems my dad put in place for me. I love experimenting with and poking at systems of all kinds, and computers have offered a wonderful playground for me.

Over time, I came to understand this thing called “software engineering.” It probably helps that my dad was a programmer and then a project manager at some large firms. I came to appreciate the craft of software development as something special. Any old coder can hack together a solution, but it takes an engineer to build a stable, maintainable, flexible system. By the time college applications rolled around, I made a decision: I would go to college to be an engineer.

Two years into the Computer & Systems Engineering curriculum at RPI, I’ve come full circle. After spending countless hours with engineers studying engineering topics, I’m coming to the realization that they don’t have it all figured out, either. Especially software engineers. Heck, software engineering isn’t even really taught at the undergraduate level. Most programmers get their degree in Computer Science and head out into the world thinking a long project is three weeks. I knew I wanted something different from that, but being able to build things “quick ‘n dirty” and understand an entire system just by poking at it is as important, if not more.

Thus, my new blog: Hacker|Engineer. Sometimes I act like a hacker, and at others I act like an engineer. I see software as a craft more than anything else, and craftsmanship requires many skills and approaches. Developing software as both a craft and as an engineering discipline is critical to technological growth as we increasingly depend on software systems in everything from communication systems to power plants. This blog will be an exploration of both hacking and engineering when it comes to software (and maybe a bit of hardware, too) development.