It never ceases to amaze me how hard it can be to sell good software development practices to business people. All they see is the dollars or increased delivery times. As a 20 year veteran(vintage?) programmer, analyst and amateur architect I like to think that I know a little about creating good software and how to do it well. However, I'm not so good at creating a business case for this.
I'm now working for a company that care about doing things the 'right way', or at least the Intergen way. We care passionately about professionalism and doing what is right for the customer - even if that means saying no occasionally. This is an ongoing battle however, we are not perfect at it. We are still subject to the whims of business requirements and real world financial constraints.
I'm currently assigned to a customer with a team of about twenty internal and contract developers. The code base for the current systems is being migrated to an SOA model using .Net 3.0 and some external components from 3rd parties. The business is driving hard for delivery on critical requirements, some of which are driven by regulatory agencies.
There are a number of issues with the project that I'm sure are common to a lot of other businesses. The existing code that I am working on is, shall we say, challenging, very challenging. It was created rapidly with little care for future requirements or expansion and has been patched by many developers for about three years. There is little or no documentation. Teams working on similar projects are separated physically and logically. There is no real architecture plan that I have seen. Testing is at the bottom of the cliff. There is only lip service paid to agile practices. The list goes on but despite the issues, the team still produces quality solutions that service the business requirements, to a certain degree at least.
As a fan of Team System I am very keen to see this introduced but I understand that it's a big task and may not offer a speedy fix to these issues. It's also hard to sell. Why is this? I think there are several reasons:
- It's hard to describe. Business doesn't want to hear about improved source control, work item tracking and unit testing. They want to know about reduced cost and increased profits. Describing how Team System aids in these areas is hard. The intangible benefits, like improved communication, are hard to estimate because they are very subjective.
- The perception is that it's expensive. This is clearly crap and I'm sick of people saying that it's expensive. What is the real cost of a software defect that takes eight passes through QA to be fixed? What is the cost of a defect in a shared library that stops twenty devs from working for three hours? What is the cost of not tracking defects at all? These are things that are easily measured. A few thousand dollars per developer is NOT expensive. If you think it is then you are in the wrong business.
- Developers don't want to work in a factory. We like to be creative and have freedom to work on what we want, when we want and how we want. The thought of being controlled by a large system and spoon fed tasks to complete on the production line is disturbing. Some developers take this to extremes and refuse to follow any common best practice such as writing comments, documenting systems or proving their code works. This attitude is not prevalent but it is something I encounter occasionally. It is very naive and must be stamped out! If you want to be that free, go work for yourself. Most businesses demand that you work at work and deliver something occasionally. Team System helps you focus on the work without dictating how to do it. You can configure as many or as few rules are you like.
I'm not saying that Team System is the only solution to bad practices, far from it, but it's one solution that I have seen work and feel passionate about.
So, if you've read this far then I'm hoping you agree with me, at least in part. What can we as developers do to sell good software practices? Like any expense or investment, it must be justified. You need to make a case for it. Show the bottom line. Record and measure the failures and use these as weapons. Set good examples by following good practice - unit testing & TDD does not reduce productivity, it increases it. Read and learn. Talk to your managers - if they don't listen, look for a new job - if they don't care about losing your skills then you are better off somewhere else. There are plenty of great companies out there and some of them even respect your opinion!