We’ve all been there. You inherit a codebase that’s horribly architected, riddled with technical debt, and coughs up blood if you so much as look at it. Or perhaps, there’s still life in your software, but it needs some heavy physical therapy and medication to get it healthy again. In either situation, the words refactor and rewrite will inevitably surface. What causes a refactor or rewrite? Are refactors always bad? What happens if large refactors are needed, but aren’t done? How can big refactors and rewrites be avoided in the first place?
Let me begin by stating that while nearly every manager in the software industry advocates Agile development, which is often incorrectly used interchangeably with the Scrum flavor of Agile development, there is no consensus amongst engineers and designers as to whether or not Agile or Scrum is a “good thing”. And, having practiced Scrum myself in seven different teams throughout my career, having attended several Agile Development workshops (all of which were biased towards the Scrum methodology), and having listened in on several conversations about the pros and cons of Scrum, there seems to be some confusion as to what problems the Scrum methodology is actually solving for, and what side effects it has on the overall software development process. In addition, you may have heard about Kanban as well, but aren’t quite sure how it relates to, or differs from, Agile and Scrum. Is Scrum all that it’s hyped up to be? Let’s find out.
Let me begin by stating a fact. Software development is an art. If you disagree, or don’t quite understand how this is possible, let me explain.
Despite the notion that software developers, when schooled in an academic setting, do so under the umbrella of “Computer Science” or “Software Engineering”, I find that the process of developing software is neither science nor engineering, but an art. It is more like painting and sculpting than it is classifying organisms and particles, or designing automobiles and aircraft carriers. I can safely say this, in part, because I was at one time or another an art major, a physics major, a mechanical engineering major, and a computer science major, while studying as an undergraduate. Thus, I have a unique perspective of what it is to be an artist, a scientist, an engineer, and a software developer.
Having worked as a software engineer in and out of Silicon Valley for several years, I’ve seen it all, from a mammoth sized multi-billion dollar transportation company, to a large struggling tech company, to a medium sized tech company growing up into a big one, to a tiny startup redefining an industry. Despite all of their differences, they all have one thing in common – an unspoken dilemma regarding software development speed vs. quality.