Thursday, November 29, 2007
Keeping it Simple
One of my all time favorite articles is The Complicator's Gloves on Worse Than Failure (formerly the DailyWTF). It identifies the tendency of software developers in particular to come up with overly complex solutions, usually when there is a much simpler one available.
This was the context of my latest rant to my CIO. Actually, this theme seems to play out in all my rants. Funny how that works.
While web services and the like have their place, many times they are used just because they are the cool new thing, not because of a pressing need. I know I am not the first to mention that nor will I be the last.
Whether it was years of reading asktom (for pleasure no less) or the influence of my first boss, I have striven (sp?) to build applications that are scalable yet easy to maintain.
One of my proudest accomplishments as a developer was at my previous job. A small state-contracted agency where I was the lone developer. I, thanks to a very trusting boss, was allowed to install Oracle and soon after found Application Express (APEX). In 18 months I was able to create some 350 pages of forms and reports for the organization. One person, 350 pages. I once found a job ad for a web developer to help maintain a 100 page website on a team of six. What? Six people? Really? Must be java or something. ;)
I continued to work for them on a contract basis for about six months after I left. Mostly until the new guy got comfortable. Unfortunately for me, they didn't require my services a whole lot. Yes, I could be deluding myself, I realize that...but I just don't believe it. They WOULD tell me.
Back to my point. At our organization we seem to have quite a few architects. They talk of Ruby on Rails, Java, JBoss, etc. MySQL gets a brief mention on occasion.
We have a hard enough time writing good SQL or PL/SQL, so now we're going to introduce new languages and a new database platform?
If we were a company that made software, I will probably be [mostly] on board, but we are not. We store and manage data for the business to do their job.
I do hope I am wrong about them and that they do talk about the importance of data in our organization. I just haven't see it yet.
So, put it in the database, use APEX when appropriate (95% of the time) and keep it simple.
This was the context of my latest rant to my CIO. Actually, this theme seems to play out in all my rants. Funny how that works.
While web services and the like have their place, many times they are used just because they are the cool new thing, not because of a pressing need. I know I am not the first to mention that nor will I be the last.
Whether it was years of reading asktom (for pleasure no less) or the influence of my first boss, I have striven (sp?) to build applications that are scalable yet easy to maintain.
One of my proudest accomplishments as a developer was at my previous job. A small state-contracted agency where I was the lone developer. I, thanks to a very trusting boss, was allowed to install Oracle and soon after found Application Express (APEX). In 18 months I was able to create some 350 pages of forms and reports for the organization. One person, 350 pages. I once found a job ad for a web developer to help maintain a 100 page website on a team of six. What? Six people? Really? Must be java or something. ;)
I continued to work for them on a contract basis for about six months after I left. Mostly until the new guy got comfortable. Unfortunately for me, they didn't require my services a whole lot. Yes, I could be deluding myself, I realize that...but I just don't believe it. They WOULD tell me.
Back to my point. At our organization we seem to have quite a few architects. They talk of Ruby on Rails, Java, JBoss, etc. MySQL gets a brief mention on occasion.
We have a hard enough time writing good SQL or PL/SQL, so now we're going to introduce new languages and a new database platform?
If we were a company that made software, I will probably be [mostly] on board, but we are not. We store and manage data for the business to do their job.
I do hope I am wrong about them and that they do talk about the importance of data in our organization. I just haven't see it yet.
So, put it in the database, use APEX when appropriate (95% of the time) and keep it simple.
Labels: apex, database, development, work
¶ 11/29/2007 01:00:00 AM
Comments:
Links to this post:
<< Home
I absolutely agree with you.
People like complexity just becuase it shows how much they know rather than how feasible the solution is
Post a Comment
People like complexity just becuase it shows how much they know rather than how feasible the solution is
Links to this post:
<< Home
