Friday, November 26, 2004
Hammer, nails, and programming
Ever been slapping some code together for some half ass company and they throw some stupid spec your way that just makes no sense what so ever? How did you deal with it? Did ya re-invent the wheel? or perhaps have a bout of genius and come up with a l33t hax to solve the problem? I follow a blog called the dailyWTF.com, and on there people post stupid shit programmers do to get the work done. Now I know for a fact that every programmer good or bad has some hacked up mess that they wrote at one point in time. If that code were to be posted in a public place I'm sure the original programmers would rather contemplate suicide then admit they actually wrote it. However some things just really make you say WHAT THE FUCK!!!?? For example this posting here is a really good example and it definitely sets the bar pretty damn high. For the non-programmers out there, the example shown is so bad that, it would have resulted in immediate firing had it even been proposed at the places I have worked. Some of the funny stuff on the dailyWTF is not necessarily the posted code snippets but is the people posting comments defending this shit. Part of the reason I like the site as much as I do is they don't directly come out and tell you what is wrong with the code they simply leave the WTF as an excercise for the reader.
Unfortunately my life as a programmer I inherihit my fare share of WTFs. As a matter of fact, I was asked to finish a small Visual Basic application that was offshored to India but was brought back here when the team in India simply couldn't make it work and couldn't get it done. This isn't a rant about how bad Indian programmers are, as matter of fact there are brilliant Indian programmers, just like there are brilliant programmers from every nationality. Its a rant about how the customer or the person asking to have the software developed influences the overall quality of the finished product. For example the person who "designed" and championed this small VB project was very dollar oriented, and had some ill conceived notion of what software costs to make and what is involved in the software development process. As a result, I'm sure the team in India was chosen simply because they were the cheapest this person could find. Because they were the cheapest, their expierence level was abysmal. I have a love hate relationship with Visual Basic, as a professional programmer I love it because I can rattle off programs extremely quick and I have a pleasant expierence while using it. I rarely struggle to get it to do what I want it to do. I also hate it because it is so easy to use and learn, because anyone can learn it, anyone shouldn't learn it. (Fortunetely Visual Basic's days are numbered and the RAD world has moved on to .NET and C#, aside from maintenance of exsiting programs I haven't started a VB project in nearly 4 years.)
Just because you understand the constructs of a laguage or tool doesn't mean you should have a career in the programming trade. To be a good programmer in my books doesn't mean you remember syntax or know the latest compiler tricks, you have to be a good problem solver. Any programmer through their coding, creates more problems then they solve is not a programmer.
Back to my inherited VB app, it is a prime example of a little knowledge is dangerous. The programmers on this project created more bad code then I wish to comment on. But they are not entirely to blame, the person asking for this program knows nothing about software or software development so that person cannot validate their work and hold a critical eye to what is being developed leaving the developers free reign on making bad decision after bad decision. This person also has a terrible time expressing his ideas of how the program should work, which does nothing but create more confusion for a team that is already struggling with the basics of development.
I watched a show on HGTV last night called Holmes on Homes, its about a professional (construction) contractor who gets called in to assess and fix problems created by other contractors on home renovation projects. Apparently on last nights show, it was about its worse it's been (that's what I gather from the comments, I have never seen this show before). I couldn't help but see the parallels between what this guy was doing and what I do with software. I also couldn't help but hold the home owners accountable for what happened to them. The home owners seemed like smart, friendly people however they were too trusting and didn't take the time to learn anything about home renovations. Because they kept themselves blissfully ignorant there were major attrocities being committed on their house right beneath their noses and they couldn't do anything about it. Think of it this way, once the drywall and paint is on the wall, who's really going to see or care about the engineering and construction hidden behind the drywall? It's the same with software, if the software does what it is suppose to do, who cares what the engineering and construction is behind? That is the problem entirely, as demostrated on the show last night, all of the cut corners and mistakes that were covered over by the dry wall were apparent to a professional and lead to major problems with the house. In a matter of six months mold had formed on the walls because of too much trapped moisture, all of the electrical was not done to code and was a fire waiting to happen, and the whole new additon would have rotted out within 10 years because of poor ventilation. Poor software contstruction leads to many problems, for example maintenance costs, many times a program gets written but written poorly so the next time changes are needed the whole program gets re-wrtten. Poor programming also leads to consistent failures and major security risks.
So to sum up, if you are having problems with someone you have hired to work for you or you are not satisfied with the quality of the finished work, chances are good you may just be to blame.
Unfortunately my life as a programmer I inherihit my fare share of WTFs. As a matter of fact, I was asked to finish a small Visual Basic application that was offshored to India but was brought back here when the team in India simply couldn't make it work and couldn't get it done. This isn't a rant about how bad Indian programmers are, as matter of fact there are brilliant Indian programmers, just like there are brilliant programmers from every nationality. Its a rant about how the customer or the person asking to have the software developed influences the overall quality of the finished product. For example the person who "designed" and championed this small VB project was very dollar oriented, and had some ill conceived notion of what software costs to make and what is involved in the software development process. As a result, I'm sure the team in India was chosen simply because they were the cheapest this person could find. Because they were the cheapest, their expierence level was abysmal. I have a love hate relationship with Visual Basic, as a professional programmer I love it because I can rattle off programs extremely quick and I have a pleasant expierence while using it. I rarely struggle to get it to do what I want it to do. I also hate it because it is so easy to use and learn, because anyone can learn it, anyone shouldn't learn it. (Fortunetely Visual Basic's days are numbered and the RAD world has moved on to .NET and C#, aside from maintenance of exsiting programs I haven't started a VB project in nearly 4 years.)
Just because you understand the constructs of a laguage or tool doesn't mean you should have a career in the programming trade. To be a good programmer in my books doesn't mean you remember syntax or know the latest compiler tricks, you have to be a good problem solver. Any programmer through their coding, creates more problems then they solve is not a programmer.
Back to my inherited VB app, it is a prime example of a little knowledge is dangerous. The programmers on this project created more bad code then I wish to comment on. But they are not entirely to blame, the person asking for this program knows nothing about software or software development so that person cannot validate their work and hold a critical eye to what is being developed leaving the developers free reign on making bad decision after bad decision. This person also has a terrible time expressing his ideas of how the program should work, which does nothing but create more confusion for a team that is already struggling with the basics of development.
I watched a show on HGTV last night called Holmes on Homes, its about a professional (construction) contractor who gets called in to assess and fix problems created by other contractors on home renovation projects. Apparently on last nights show, it was about its worse it's been (that's what I gather from the comments, I have never seen this show before). I couldn't help but see the parallels between what this guy was doing and what I do with software. I also couldn't help but hold the home owners accountable for what happened to them. The home owners seemed like smart, friendly people however they were too trusting and didn't take the time to learn anything about home renovations. Because they kept themselves blissfully ignorant there were major attrocities being committed on their house right beneath their noses and they couldn't do anything about it. Think of it this way, once the drywall and paint is on the wall, who's really going to see or care about the engineering and construction hidden behind the drywall? It's the same with software, if the software does what it is suppose to do, who cares what the engineering and construction is behind? That is the problem entirely, as demostrated on the show last night, all of the cut corners and mistakes that were covered over by the dry wall were apparent to a professional and lead to major problems with the house. In a matter of six months mold had formed on the walls because of too much trapped moisture, all of the electrical was not done to code and was a fire waiting to happen, and the whole new additon would have rotted out within 10 years because of poor ventilation. Poor software contstruction leads to many problems, for example maintenance costs, many times a program gets written but written poorly so the next time changes are needed the whole program gets re-wrtten. Poor programming also leads to consistent failures and major security risks.
So to sum up, if you are having problems with someone you have hired to work for you or you are not satisfied with the quality of the finished work, chances are good you may just be to blame.
