# Wednesday, August 04, 2004

I realize this is a rant, and not strictly technical, but here's one soapbox (among many) I'm willing to step up to. 

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.  As a further complication, people who are tightly focused on a particular domain tend to make things sound way more complicated than they turn out to be because they aren't building their models at the right level. 

When it actually comes down to writing the code to implement the loosely defined business system, it's almost always "just code".  Not challenging to write, often tedious and time consuming, but not in any way difficult from a CS standpoint. 

So, the challenge when writing such software is in cutting though all the BS to get at which little bits of "just code" you have to write.  Once you get that part out of the way, the actual coding bit is easy.  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. 

Along the same lines, anyone who's looked seriously into enterprise level web services understands that the barriers to real business to business communications aren't technical barriers.  They are organizational.  If only two or more businesses could agree on what the schema for a purchase order should look like, we'd see a real renaissance in B2B computing.  The technologies are all there, the hard part is getting the organizations to work together.  That's the problem to solve.