Patrick Cauldwell points out that the challenge of coding a business app isn’t in writing the code, that’s easy. The challenge is in understanding business requirements, and not because developers and architects can’t understand plain English.
In my experience, I find that often, “business people” (for the lack of a better word) do not apply the same rigor to developing a business model for an application as developers do towards requirements gathering, specifications, and coding for the application.
I understand that agile methodologies are designed to help manage change, but even they can’t keep up when the business owner doesn’t even know what the requirements should be, but is spouting them out anyways. What do you do when the business owner has been involved in every step of the project, played with every prototype and interim release, but at the end says, well that’s not what I want.
For ~95% of business software, the actual code needed to implement them ends up being, if not trivial, then at least not technically challenging. Business software projects go over budget/schedule etc. because the business rules aren’t known (to anyone) or because no one in the organization really knows what they want. ...snip...
So when people complain that projects are going way over budget/schedule/what have you, it’s almost always (in my experience) due to the fact that engineers spend 6 hours a day poring over vague and conflicting sets of documents, and 2 hours writing code.
[Via Patrick Cauldwell’s Blog] As a developer friend of mine used to say,
This job would be great if we didn’t have clients.
Of course I prefer the paycheck.