Wednesday, January 21, 2015

Solution-Providers

This article is one in a series. See the introduction here.

Solution-providers are passionate about what they do, but in a very different way. While the others kinds of developers that I've mentioned care deeply about the inner-workings of the software and how it is structured, solution-providers care about the user experience.

Don't be fooled, mind you; just because they are geared towards meeting the users' needs doesn't mean that they are necessarily good people-persons. Many of them are still the typical anti-social developer that you would hesitate to introduce to clients. It's not their people-skills that identify them as a solution-provider; it's what motivates them that matters.

Solution-providers get thrilled by the problems that their product is solving. They are often the feature-visionaries that dream-up all sorts of amazing things that the software could do. Where other impassioned developers tend to find roadblocks (e.g. "that would take too long", "we'd have to refactor our existing architecture to support it", "it would complicate deployment"), the solution-provider paves ahead full-speed because they are focused on the end-of-the-road. Often, to the shock (and sometimes horror) of the others, the solution-providers are usually capable of achieving their objectives in brilliant fashion.

Where the others will want to write most of their components in-house (either because they enjoy the challenge or because they want more control over how it fits into their design), the solution-provider is quick to make use of any, and all, of the third-party libraries at their disposal. If what they need to do doesn't fit well into some existing framework, they'll just hack their feature in as best they can, or make a whole new custom framework, or just skip the framework altogether. In their minds, if the framework is getting in their way, it's their enemy. They don't care how much damage it might incur, as long as they get the feature implemented.  For whatever reason, perhaps due to a lack of attention-to-detail, they also very commonly have poor writing skills, especially in intra-office communication.

When you have a design meeting to discuss new features or user-interfaces, you want to make sure that your solution-providers are there. When you need to implement a well polished user-interface, assign it it a solution-provider. When you need something done fast for an upcoming sales-demo, ask a solution-provider to do it. If you are worried that a project is getting mired in over-engineering, add a solution-provider to the team. Solution-providers are great for rapid-application development and impressive user-experiences. They are also particularly useful for writing one-off applications which will not require later-support.

As you can imagine, solution-providers are a very valuable addition to almost any team. In fact, I'd venture to say that they are almost always the favorites of those in management. Managers like assigning tasks to solution-providers because they know that the solution-provider will  not argue over the design, they will have some great ideas for enhancements, and they will implement it quickly. Not only do the managers get what they want faster and with less headaches, but the product is typically flashy and looks great in demos too.

All of these things are big positives, but, as a manager, you have to be careful to not get too enamored with your solution-providers. It's easy to be skeptical of your other developers because their weaknesses are more obvious. Remaining mindful of the weaknesses of your solution-providers requires more discipline. It's difficult because most of their weaknesses do not exhibit side-effects until after the project is done.

Your other developers weren't just being sticks-in-the-mud when they harped on all of those roadblocks. All of those shortcuts that the solution-provider took will have long-lasting consequences. Every corner that was cut in order to save a day of work will cost you another ten days to fix later. Every framework that was bent out-of shape so that a new feature could be crammed into place will eventually crumble under its own weight. Not only will their software be more buggy, but it will be harder to fix the bugs too. Each time that you ask a solution-provider to add another new feature to their original product, the man-hours will mount as the technical-debt takes it's toll. Eventually, they will reach a point where they--the very ones on which you rely for roadblock free development--will tell you that certain new features are not feasible.

Sometimes, in business, you have to cut corners. The profits, deadlines, and bottom-line cannot always be ignored for the sake of perfection. That's fine--everyone should be able to understand that--as long as you are doing so with full awareness of the consequences. Plan for the consequences. Take the time to clean-up the mess as soon as possible. Don't ever allow a solution-provider to dig their own-grave. No one wants that. It's not good for anyone.

No comments:

Post a Comment