Today I got an email from a guy who appears to have become disillusioned with what he sees in our industry. Unfortunately I, and probably a large number of other developers, can relate with his frustrations. To summarize his email, he’s basically saying “I can’t believe that we do this to clients”. ‘This’ could be anything you’ve seen or imagined in the past; Low (poor) estimating with expected over-runs, dropping the application in the client’s lap one month before go-live and expecting them to test it and be happy with the what is provided, business requirements not being gather and having developers make their best guess. The list could go on and on.

I’ve seen all of this in the wild. Heck the project I’m currently leaving has this in spades. So why do we continually do this to the people who pay our rent? I could just tramp out the Agile Manifesto here and start saying how it can work with you to reduce the friction between your team and the clients, but I’m not. Instead I want to explore what makes us think we can or should run our projects in these ways.

Software development (for LOB applications) usually happens in a sequence of events. First, a business decides that they need software to help them run their business. A project is struck and a team (internal or external) is raised to begin creating the software requested by the business. The project team works away at the SDLC and produces an end product (software we hope). The business implements the software as part of their business and said project ends its initial development life cycle.

In all of those steps there is one constant…the business. They start the process by creating a need for a project. They participate during the running of the project by dictating what is required in the final result. At the end, the business takes the software and works with it, ensuring that payment was made for the work done.

Those steps can be translated into: The business creates a job for people doing software development. The business dictates the results that they expect from those people they have created employment for. The business consumes the final product created by the people in their employ. Interestingly, when we look at it this way, we (software developers) owe our employment and paychecks to the business.

For me this points out two things. One is that we developer work for the business at a larger level than is normally acknowledged. Secondly, the business should demand more from us as our roles were created to meet their desires and requirements. What I don’t understand is how it has become so regular and common place for software development projects to dictate to the business.

When did it happen that we could get away with statements like I’ve heard in the past year?

The business needs to change because of how we implemented the database.

Or

I’m gathering all the BAs and dev leads so that we can decide what client stories we will remove from the project for go live.

Why do we feel so capable of telling a business what it does or doesn’t need? I have no idea how to run any of the businesses that I’ve built software for. I may understand things in their terminologies and even how those concepts relate to each other, but I have absolutely no idea how to take that information and translate it into a sound business decision. My job, as a software developer, is to help the business have the information necessary for them to be able to make those decisions.

The business should be relentless in their desire to have the information that they need. They should also be aware that sometimes we can’t display something in the way that they want. There is a difference between we can’t for technological reasons (how do you create a 4 state checkbox?) and we won’t because the development team (including the BAs) doesn’t think it’s needed.

Often the ‘can not’ and ‘will not’ statements get blurred together by the project team in an attempt to turn the ‘will nots’ into ‘can nots’ for the project teams benefit. Instead the project should be actively looking for ways to minimize the occurrences of ‘can nots’ and eradicating the ‘will nots’. If we are going to build software that actually does serve the business in the way that they are hoping for when they initially strike the project, we must do this. Allowing projects to deteriorate, which they seem to start doing immediately upon their inception, into a stream of ‘can nots’ and ‘will nots’ is a sure fire way to have the business consider the final product a failure.

Don’t think that I’m all about the business getting everything that they want all the time. I think that it is imperative that the project impose some of the same caveats on the business that the business desires on the project. If they are giving the project a set in stone completion date, it’s not unreasonable (in fact it’s probably prudent) to put time constraints on their decisions. Because we are in this together, there has to be an expectation that each party will work to ensure the success of the other.