Writing Business Software Easy?

I read a blog post the other day. I can't find the URL but it was basically saying that writing business applications is easy, and boring. The writer said that standard CRUD type code is so fundamentally easy, that anyone could work it out.

This is true. An entry level programmer can easily work out how to code CRUD level code, in a standard business application. BUT. That is one very, very small part of writing a business application. I have been writing code for well over 10 years now, so I think I have enough experience now to categorically state that writing business applications is easy, but architecting apps is hard. Very hard in fact.

It takes a good deal of experience, trial and error and frankly, cock ups, to get the sort of experience needed to architect a successfull business application. The main problem lies in the fact that there is many ways to skin a cat, and no one way is better than the other. It takes someone with a wise head to think through the issues and come up with the best approach for that particular application.

Take for example, a typical n-tier application. There are many questions you need to answer before you can start coding.
Things like:
- how will you pass data between tiers? DataSets? DataReaders? Custom Objects?
- how many users will be using the app concurrently?
- what are the possibilities of deadlock issues?
- what sort of lock mechanism do you need? Table level? Row Level? Field Level?
- will the tiers be located in different sites? If so use web services or remoting?
- what are the chances the data provider will change? Use a data factory pattern?

I could go on. These are easy questions to ask, but not so easy to answer. It takes someone with knowledge and experience to even know what questions to ask, let alone come up with the correct answer.

So, is writing Business software easy? Maybe, but only if it is architected well.

Programming
.NET