Bad coding = life pain for users
My first experiences of coding, I still maintain, were very good for me. We had no memory, no processor speed and no clever display stuff. Life was a struggle, disks were so big you could not carry them. So fragile you dare not breathe on them. Tape storage would mean the endless loss of your hard tapped in machine code.
So we would write workng code, then tighten it up, then tighten it up again just to get it to run as fast as we could. But this practice seems to have diminished in recent years, both large and small corporations, instead of looking at profiling code properly are just buying bigger kit to run the badly written code on.
Some clients get to the point where the hardware guys are blaming the software and the software guys are blaming the hardware and neither can prove the other right or wrong.
Just recently I saw an SQL server with only 80 users (only 80!) and 4 processors and 4gb of ram running like a dog at 100% usage most of the time. The software developer had used the “access upgrade wizard” and not bothered to index the SQL server’s database. Now the same SQL server is running at about 40% at very busy times. Not bad considering the customer was about to spend a lot of money throwing hardware at the problem.
Once I’d got into the software things became even worse. The users were waiting up to a minute and a half for a screen to appear. Ok the software WAS written in Access 2000 (yes I know, not a good choice for an enterprise system that runs 24 hours) and had been festering for a couple of years. After getting hold of the source and rewriting a lot of it I got the screens loading almost instantly.
The problem was simple. The software developer was used to 5 user networks. So they didn’t care about the speed something loaded “it’s ok here!”. His programming style was fine for a small company but disaster for a larger one.
Please people just think about your code.
You are running on a one user machine – if you’re a professional developer you’ll probably have a pretty good machine to run it on. Most developers never feel the pain of the users. It’s easy to be protected by salesman who shrug their shoulders and can’t help when faced with an irate user. Sometimes the developer needs to go sit with the user and see the users pain.
What we need to do is to have pride in our code. Squish it down to it’s most efficient. Get rid of all those loops unless you really need them. Learn how to optimise SQL usage and make the best of the equipment you have. Remember years ago whole corporations, (and big ones) ran on less hardware than you have on your desk. We had to write the code then submit it to be run and wait for the result, which when you are a junior programmer might not come back till the next day with “Syntax Error Line 5”.
Lisp – Boot camp for programmers
One of the things I love about Lisp is it’s elegance. The way it drives you to write elegant code, “oh too many brackets”, I hear you cry. But get past the brackets and you’ll see something really great. Every programmer should learn Lisp, it will make you laugh and cry, swear and keep saying “oh Wow”. Lisp has a very very steap learning curve. When you “get” Lisp it is almost like a religious experience but one that will affect your coding for the rest of your life.
Lift your glass to the easy programming!
With the advent of the “easy” programming with NetBeans I hope we don’t become LAZY programmers. I hope we still look at our code and imagine what would happen if 100,000 users were running it. Netbeans and Glassfish give us a platform to build an awesome scaleable solution, so make every byte count. Every processor instruction worth the work.
So get out there and write beautiful, beautiful code.