What Would You Say…You Do Here?

As a software development/technology implementation gun for hire, one of the primary hesitations that many prospects have with committing to an engagement is the belief that the things that they do, and the solutions they build, are so fundamentally complex that it would take months for an “outsider” to gain inertia and contribute value. This is oft stated in the classic bit of wisdom that you shouldn’t expect new hires to get up to speed for months.

This is a problem. Where it is true, it is often because of organizational dysfunction or malaise. It is a state that all firms should strive to escape, and is seldom a given unless you’re working in something really distinct, like particle accelerators.

whatwouldyousay

I’ve written about this general idea before in the piece Outsourceability as a Measure of your Software Development Process.

If building your solution requires various undocumented manual steps, you have a problem. If resources necessary for the project are found in varied, random places, you have a problem. If the team views the solution as a mystery meat of magical solutions, and fails to understand the basics of the domain, you have a serious problem: I’ve encountered financial projects where some participants thought calculating the IRR (Internal Rate of Return) was such a mystery that touching the code meant having to reverse engineer the entire project. Understanding the basic problem being solved was a more viable approach.

If the code is so intertwined and coupled that doing anything to any part of it requires walking through and tracing the serpentine execution through hundreds of thousands of lines of code, you have a problem. If being able to work on the project requires being a domain administrator and a database administrator, and have access to the entire source code universe of the organizations, you have a profound security problem.

All of these are excuses why a team can’t integrate help, and every one of these factors sabotages the long term health of the project: These are things that are serious problems even if you never, ever plan on making use of someone like myself. Even if you have a team of four developers who have committed their lives to staying with the organization and only working on that project, this is still critical issue that needs to be fixed: these are the canaries in the coal mine — the gas is leaking in, and it won’t be long before the project is dead if you don’t notice and resolve them.

I’ve worked with clients who’ve had all of these problems (unchecked it becomes a natural state), and we quickly and efficiently cleaned them up for the future. I happen to be quite talented at using heuristics to make the best of a bad situation, still pulling fantastic success out of conditions that would generally lead to failure, but this is not the norm. These are problems you need to fix.