Who Owns Your Code?

At work, our marketing team is in control of deciding where development spends time on products. This is an effective way to ensure that our product meets the needs of the market we're in.

In fact, I would say we have an effective backlog of "big features" that are desired by our target market. We're only limited by the resources we have on hand to deliver these features. Therein lies the challenge; almost every feature is done on a tight timeline, and once it's in a non-laughable state, it's released and the team goes on to the next big feature. No time is really spent revisiting the overall design of the product, or just bringing its dependencies up to date.

In a previous workplace, the development team had strong say on what was worked on. This was an effective way to ensure the product was relatively nice to work on and its technology up to date. New features were strongly scrutinized and often there was a focus on picking newer technologies that made it easier to develop and service. The challenge was we'd fall behind on bolting on new business features from time to time.

In yet another workplace, our SEO team had the strongest say in what happened. Our main products were publicly accessible websites, but I feel like this was a pretty unique situation. Many technical decisions had to be discussed with the SEO team (which CMS should be chosen, which captcha system should be employed, etc..) and everything from character set encodings, performance trade offs and cache expiry times needed to have their approval. Our challenge there was that the success of some SEO practices are not easily measured, it was difficult to assign a ROI on particular decisions.

Who owns your product? How does that shape it?

Negative Velocity Developers

I've worked on a handful of projects over my career where there's been a developer that I've started to coin as "negative velocity".

Their positive impact on projects is best when they're on vacation or spinning their wheels in meetings. Everything they touch could instantly earn an @Deprecated annotation, and often when they're focused on their next tasks, the rest of the team is left to either throw out and rewrite, duplicate in parallel or at best refactor the work they've done.

Some of the best code they write is copy and pasted from other code, some of the worst is of their own design. Often the team works hard to try to minimize the impact of the developer, but they simply just don't understand what they're doing.

Agile projects make the results of this developer even more vicious as they get to choose what area of the project they will molest next. Also, many teams are "agile but" where the team follows some practices, they are not empowered to remove that developer from the team.

Often those that make employment changing decisions don't have the tools to validate such a claim. So what's one to do with a negative velocity developer? How does one capture enough information to prove to someone non-technical that their skill sets would best be used elsewhere?

Note: This is not a current situation for me.