What you are seeing are solutions developed in a vacuum without regard to the domain knowledge necessary to understand that a problem needs to be corrected and not "worked around". Essentially, when developers lack the domain knowledge around identifying and correcting problems in areas outside of software, you end up with software developed that works around or bandaid across issues. Essentially, they don't know how to diagnose or correct the problem, diagnose the effects of the problem, or in many cases, even understand that it is a problem.
In some cases, you need strong managerial leadership to stand up and make things right. The problem may be exacerbated by weak management or politically charged environments where managers manage to the Green. And some problems do need escalation.
This gets very dangerous to an IT environment for a multitude of reasons including:
- It masks a problem. Once a problem is masked, any fix to the real problem breaks the developed bandaid solution.
- It sets an even more dangerous precedent in that now its OK to develop bandaid solutions.
- Once developed and in place, it is difficult to replace the solution. (It is easier to do nothing.)
- It creates a mandate that further development will always be required because of the work arounds in the environment. In essence, no standards based product can no longer fulfill the requirements because of the work arounds.
A lot of factors contribute to this condition commonly known as "Painted in a Corner" development. In essence, development efforts paint themselves into a corner where they cannot be truly finished or the return on investment can never be fully realized. A developer or IT organization cannot divorce itself or disengage from a product. In effect, you cannot finish it!
A common factor is a lack of life cycle methodology in the development organization. Without standards and methodologies, it is so easy for developers to skip over certain steps because of the pain and suffering. These elements include:
- Requirements and Requirements traceability
- Unit Testing
- System Testing
- Test Harnesses and structured testing
- Quality Assurance
- Coding standards
- Code / Project refactoring
- Acceptance Testing.
This is no different from doing other tasks such as Network Engineering, Systems Engineering, and Applications Engineering. The danger is that once the precedence is set that its OK to go around the Policies, Procedures, and Discipline associated with effective Software Development, it is very hard to reign it back in. In effect, the organization has been compromised. And they lack the awareness that they are compromised.
Sometimes, development managers tend to be promoted a bit early in that while they have experience with code and techniques, exposure to a lot of different problem sets segregates the good development leaders from the politicians and wannabes. Those that are pipelined do not always understand how to reason through problems, discern the good from bad techniques and approaches, and lead down the right paths. Some turn very political because it is easier for them to respond politically than technically.
What are the Warnings Signs?
Typically, you see in house developed solutions that are developed around a problem in functionality that would not normally be seen in many different places. This can be manifested in many ways. Some examples or warning signs include:
- Non-applicability of commercial products because of one off in house solutions or applied workarounds.
- Typical terms like "thats the way we've always done this" or "We developed this to work around..." arise in discussions.
- You see alot of in house developed products in many different versions.
- In house developed products tend to lack sufficient documentation.
- You see major deviations away from standards.
- No QA and code review is only internal to the group.
- No Unit or System test functionality available to the support organization.
- In house developed software that never transitions out of the development group.
- Software developed in house that is never finished.
- You get political answers to technical questions.
One must be very careful in the design and implementation of software done in house. If wrong, you can quickly paint development and the developed capabilities into a corner where you must forklift to get functionality back. And if you're not careful, you will stop evolution in the environment because the technical solutions will continue to work around instead of directly addressing problems.