September 12th, 2009
As Albert Einstein has been quoted as saying, “Two things are infinite: the universe and human stupidity; and I’m not sure about the universe.”
*** Warning: this blog entry is a rant. The opinions expressed here are entirely mine, and do not necessarily represent the opinions of my employer, whose website links here.
The more I observe human behavior, the more I agree with Einstein on this issue.
I’m not, as you might expect, just talking about the domain of software engineering, but of course, that’s included too :-)
Here are some of my favorite recent examples:
- The current healthcare reform “debate” in the U.S. – many people who have insufficient health care coverage or who are a single medical event away from potential bankruptcy argue vehemently against reform of healthcare delivery and insurance. This is in direct opposition to their own self interests, and seemingly serves no-one but the insurance companies. In the expression of their opposition, they do radical things, like continually repeating bald-faced lies, and verbally assualting the President during a formal address, on live television. Yet they call themselves “conseratives”, and so does the Media. All of these actions seem to me to be blatantly stupid.
- Several years ago, I worked for a small software consultancy (not my current employer), where I “inherited” the maintainence and continuing development of a custom application for a State agency. The application had been written as a one-off “solution”, was written in MS Visual Basic, and used an Oracle database. The VB code was hard to maintain, which tended to drive up the cost of maintainence and new feature development, and after a year or so, the customer also noticed that the Oracle license was costing them a huge pile of cash each year, as was the Windows Server license. They asked if we could switch to a different database. Unfortunately, the cost of doing so was prohibitive, because much of the business logic was in Oracle stored procedures. About a year later, the consultancy signed contracts with the equivalent agencies in two other states, to provide them with software with functionality similar to that in the software for the previously mentioned agency. It wasn’t workable to modify the original software, both because it was so specific to that particular customer (again, it was a custom “solution”), and because of the same issues that made it hard to maintain. A ground-up approach was in order. Lessons learned would be applied. I led a team that wrote a framework for the general problem domain, and then customized implementations on top of that framework for both new customers. We used Java, and ran it on Tomcat on Linux. We used Hibernate, and put all of the business logic in a coherent, well-designed “business tier” of the Java application. We were able to switch databases effortlessly, and did so. The application ran on mySQL, Oracle, and SQL Server, with only a simple change to one configuration file. No vendor lock-in required. No licenses required. All “free” software. Success! Fast-forward a few years – I recently heard that the original state agency (the one with the VB app.) finally got together the funding to completely re-write their application. My former employer did it in C#, no doubt with SQL Server, on Windows Server. Cost – unknown. Vendor lock-in – complete. Stupidity – infinite.
- On my current consulting project, the customer is already heavily invested in the Seam framework, so the new application that we are writing for them is also using Seam. I’ve never worked in Seam before, so I’m just coming up to speed – reading documentation, looking at sample code, etc. I’m mostly working on JPA code, but within the Seam environment. Yesterday, I wrote code to satisfy the first few use-cases. Domain objects, services, and some database access via JPA. Ok, now it’s time to test that code. I read the Seam documentation – it shows how easy it is to test Seam components, even JSF functionality. I wrote up my first test (subclassing SeamTest, as shown), and…the test won’t run. It looks like the SeamTest has failed to set up the JPA environment, and it’s looking for an “InitialContext” so that it can get the transaction manager from JNDI. Ok, that’s not too surprising – so I go back to the documentation to find out how to set up a test that includes JPA – except that there apparently isn’t any. A trip to Google-land shows about what I expected – hundreds of individuals asking about how to solve this problem, and not one single coherent, step-by-step answer. Further reading turned up the gem from the Seam folks that they don’t believe in unit testing, only integration testing. Looks like they believe that integration testing means “slap all of your code together, from all tiers, untested, deploy it, and try out things from the user interface”. Apparently, they think that this approach makes software development faster. The point that they clearly missed is that actual contruction of software (i.e. writing code) is typically a very small percentage of the time and cost involved in the total software lifecycle. The real costs come over time, after initial deployment, when the code has to be maintained, and new functionality added. That’s when unit and integration tests are priceless. Even in that initial construction phase, on-time delivery of a quality product still demands good design, good planning, and early, frequent, comprehensive testing at all levels – and this includes both unit and integration testing. The Seam folks and their adherents think that they are saving time by not testing properly. This makes about as much sense as re-writing your application exclusively using Microsoft technologies because you have been burnt in the past by vendor lock-in. It makes about as much sense as poor people arguing against reform of the healthcare industry, or for big tax breaks for the rich.
Stupidity is indeed infinite.
Posted in Uncategorized | No Comments »
Keeping It DRY – Automation of Repetitive Tasks
Working with the 
