Sometimes prospective clients ask me about the benefits of having software veterans building their applications versus using less experienced developers. At Haught Codeworks, the team is pretty senior heavy with half having 10 years or more of experience in the industry. While every developer is different, I have noticed some common traits in experienced developers. One of the most significant is an instinct to solve a problem instead of just implementing a requested feature. It’s a subtle distinction that I think is important.
As a less experienced developer, there’s a tendency to assume everyone else knows what they’re doing and has a deep understanding of the business domain. When presented with a feature request the newer developer will immediately dive into how to implement the feature, eager to get started on a new problem. The assumption is: “The client has asked for this feature so of course we should build it.” This approach leaves some obvious questions unasked: What if the feature is a bad idea? What if there’s a better way to solve the real problem behind the feature request?
The eagerness to dive into feature implementation prevents getting the full context and “the why” of the problem. In my experience software veterans are more likely to view a feature request as one solution to a more general underlying problem. We’ve built so many features and worked on so many different projects that we’ve seen the damage reckless feature development or building the wrong thing can do. We’ve learned the hard way to be cautious about features and to question – gathering the full context of the problem first.
Early in my career I realized the value of asking these sorts of questions. Why this feature? How will this help your business? Why don’t we do it this other way, which is easier? These kinds of questions aim to discover and solve the true problem at hand, rather than just implementing one preconceived solution. This kind of thinking is so important to me that I try to stress it in the culture of Haught Codeworks. I encourage even the apprentices to approach each feature request with caution.
I joke that my job is to say “No” to a new feature until I can be convinced to do it. I want to test up front that a new feature is worth building. Usually clients will have good justification and I’m easily satisfied, but sometimes these discussions make everyone realize an idea might not be as great as it first sounded.
Hidden Costs and Complexities
Another common trait of experienced developers is knowing the hidden costs and complexities in a feature. Developers have access to technical information that clients typically don’t. Sometimes when given the ramifications of implementing a feature, other alternatives start to look better. It’s common that non-developers will assume a feature is simple and shouldn’t be hard to implement. When all the hidden costs and complexities are exposed, non-developers start to see why adding that feature won’t be as easy as they thought.
For this reason, it’s better to describe the true problem to the development team and not just one proposed solution to that problem. Once the developer knows what is really wanted, they can brainstorm ideas on the best and most efficient way to solve that problem. Experienced developers understand this and make it part of their process by default.
Building Better Solutions
There’s another intangible benefit to experienced developers: knowing how best to solve common business problems. I’m not sure when it happened but somewhere past my 10th year in the industry and 20th project, I had built up a store of knowledge that went beyond how to technically implement features. A few examples that come to mind are modeling complex domains that make sense to technical and non-technical people, what user interface solutions worked best, and how to take care of users. I’m not alone in that many of my fellow veteran developers have also accumulated what I consider business wisdom. Just this year I was emailing one of our clients about details of the business domain and he replied with this, “You’ve helped us thinking through our customer experience, customer service processes and strategies for the business. You’re a sounding board, and solid strategic thinkers. You listen well and then provide insights and ideas versus coming to the table with a ‘this is how the technology can do it so we must do it this way.’”
Newer developers haven’t been exposed to these nuances of how software is applied to business. This is one of the reasons that Haught Codeworks has veteran developers deeply involved from the beginning, so they can pull in wisdom from working on dozens of software projects.
Why is this Important?
I have yet to encounter a project where time to market or project budget wasn’t of the highest importance. Figuring out how to efficiently understand and solve the true problem at hand is incredibly valuable, and doing it early is the key to reducing wasted effort. This mindset is core to how Haught Codeworks tackles projects and we pride ourselves on figuring out the fastest, easiest way to solve the problem. I tell prospective clients that we are an investment in their product and business, and experienced developers help make the most of that investment.