I spent several of my last few days on my last job tidying up design documentation, javadoc, and header comments before leaving. Some parts of the header comment template were useless. How many hours was it worth to have me go through and label each file with its file name, author, and creation date? I doubt that in the year 3007, the historians of that time will be browsing millenium-old source code header comments to gain insight into our life and times. And if I’m wrong, they’ll probably do what we do now and check the repository change history. As it happens, a good CM system will keep track of who checked something in and when. Most astonishing of all, it’s quite easy to figure out the file name by… I dunno… looking at the name of the file on the file system? Believe me, I’m all for sensibly applied engineering rigor, but sometimes the wrong tool for the job just ought to be put back in the tool box.
The Wrong Tool for Every Job
May 5th, 2007 by jeffreyThere He Was… Gone
May 5th, 2007 by jeffreyI’ve switched jobs again. Actually, I went back to my previous employer. That in and of itself is of no use to you, so I’ll skip over it. There are, however, some lessons from my now ex-employer that are worth learning if you want to retain your employees, or I suppose, if you want to drive them away in droves.
Read the rest of this entry »
Why My Broken Air Conditioner Poses Challenges for Reputation Systems
March 25th, 2007 by jeffreyOver this past summer, our air conditioner failed. It wasn’t a quiet failure of the compressor. The outflow line for the condensation water blocked up and sent water down over and through the oil furnace below. In looking at the state of the HVAC system, particularly the oil furnace, it became apparent that they had been poorly maintained for a lengthy period of time, despite our service contract with our oil company. Getting recommendations from neighbors and friends is one way to help avoid this kind of abuse of trust. Many sites on Teh Intarwebs use reputation systems as well, but most are oriented around transactions with short durations. Many industries, including health care, HVAC maintenance, accounting, and investment work over considerably longer periods.
Read the rest of this entry »
Another Toe Tagged Project
November 1st, 2006 by jeffreyI was recently asked to go take a look at a web site project. Ordinarily, my answer to requests for a critique like this is, “Are you willing to pay my ‘I don’t want to do this,’ rate?” This person, however, I owed. Big. I almost asked, “Would you be willing to take an internal organ instead? I have a spare kidney!” I don’t think she would’ve taken it. She wanted the web site reviewed. And so I began my foray into a text book case of all that can go wrong in web development.
Read the rest of this entry »
Application Service Providers and Beef Bouillon Flavored Jello
September 12th, 2006 by jeffreyMy workplace shares our street with a goodly amount of vacant class A office space. Apparently this space was left vacant by an Application Service Provider that went from being the largest technology employer in the county to bankruptcy court in record time. A few years ago, we were told ASPs were the way of the future - the desktop was dead, and a brave new era of applications served from the net was revolutionizing the way we worked and played. Now most of the revolutionaries are dead and buried, and the few remaining ASPs look like they’re trying to sell to large enterprise customers rather than you, me, and everyone. To me, the interesting question is, “Why?”
It’s because application service providers were trying to serve beef bouillon flavored jello.
Test-wide Setup and Tear Down of JUnit Tests
August 17th, 2006 by jeffreyJUnit 4.0 introduces the @BeforeClass annotation, providing a way to run a class-wide setup method before any of the tests in that class are run. The analogous @AfterClass annotation allows for tear down of those fixtures. I work on a project that hasn’t yet upgraded to JUnit 4.0, and although less widely publicized, it is possible to accomplish the same thing with 3.8.x.
Think before doing this. Tests should be independent of one another. If your tests share fixtures, side effects from one test could affect the results of others. Sometimes, however, a test fixture is just too expensive to set up and tear down with every test. In my case, I needed to set up a database and import a substantial quantity of data. Doing this for every test would’ve made the suite prohibitively slow.
Read the rest of this entry »
A Plea for Configuration Management Sanity
August 12th, 2006 by jeffreyI’ve taken configuration management and revision control for granted. I first lost work because I wasn’t using a repository system early in life, and I resolved that such a thing would not happen again. During my senior year in college, I was working on a project with a randomly assigned classmate. When we started, I explained I’d set up a CVS repository for the code and gave him the directory for CVSROOT. Next time we met, he told me he didn’t have any trouble finding the code, but asked why the file names had commas and a couple random letters at the end of them. In retrospect, it was wrong of me to laugh, but I honestly thought he was making a joke with a deadpan delivery. When I walk onto a project, I can make an educated guess about how it’s going to go based on how much work it takes to get up and running with the SCM and build system.
Read the rest of this entry »
Skating at Work
July 15th, 2006 by jeffreyYears ago, a few friends introduced me to a new use of the word “skating” to mean shirking one’s work responsibilities. One is skating when at work, seemingly productive, and deliberately accomplishing little or nothing. Note the difference from other forms of work avoidance, such as absenteeism. One of the best executed examples of skating was a guy helping clean a building. He spent an entire week with a bucket of soapy water and a sponge sitting and looking out a window. When someone came by, he wiped the sponge over the window a few times. When left alone, he went back to looking out the window.
I just left a job where I worked in a department of about fifty people. Some of them were the best with whom I’ve ever worked. Others were a questionable use of perfectly good space, light, and breathable air. Among the latter, I observed repeated and common threads that begin to form a pattern language of skating. I catalog a couple of them here not to encourage their use, but to suggest ways to detect and counter them.
Please keep in mind that the goal is to drive toward getting the work done, not to assign blame. I don’t care who shot John; I just want to make sure we don’t shoot him again.
Read the rest of this entry »
Job Listings and Past Experience
July 9th, 2006 by jeffreyI started this blog now because I believe I’ll have more free time to devote to hobbies. I’ve just switched jobs. As I looked at my options, I read many listings for software engineers. The emphasis these listings placed on experience in a particular programming language, tool, or framework was disappointing.
Requiring that a programmer must have experience in one particular language or tool is like insisting that a waiter must have experience waiting tables at a seafood restaurant. Who cares if his experience was at a steakhouse instead? The essential skills, knowledge of how restaurants operate, and ability to deal with difficult customers are the same. If he’s thrown off because the plates have steamed crustacean on them instead of grilled cow, he’s no use to me anyway.
I’ve heard the counter-argument. “But steak and lobster have such different centers of gravity, so the plates balance differently. And it’ll cost us a lot to teach him the particular gotchas of this kind of food, like not letting the lobsters catch his fingers with their claws!” The idea here is that every language and tool has unique quirks, and that a developer must have experience with those quirks or they’ll get mired in a productivity sapping tar pit of small mistakes. There may be some truth to this argument in the first few days on the job, but not over the medium and long term.
I’m not dismissing the value of experience as a whole. The right kind of knowledge and experience are valuable. More experience working as a developer is better than less. I’m now a far better developer than I was five years ago. I’ll be better still in another decade. Domain knowledge and experience, too, are more than surface deep. Picking up a thorough understanding of a problem domain takes time, and in the meantime the less experienced programmer may do some amount of well-intentioned harm. Don’t expect someone with a background in developing UML modeling tools to produce a good design for a real-time, embedded signal processing system. Those distinctions make for better hiring criteria than years using a language or tool.
Read the rest of this entry »
On Blogging
July 9th, 2006 by jeffreyWhen I first became familiar with putting up personal web pages, I thought “I’ll never do that.” Such is the power of the word “never” that shortly thereafter I had a few small pages. The “Infrequently Asked Questions” title stuck to those pages because it seemed doubtful that anyone else would get any use out of them. I haven’t updated them in years, but they remain online because I still get an email every few weeks thanking me for them.
When I first became familiar with blogging, I thought “I’ll never do that.” Such is the power of the word “never” that… here we are.
There are a number of thought provoking and useful blogs online. There are also legions of bloggers writing diaries without the good taste to hide them in their sock drawers. That latter category doesn’t hold much appeal for me. I’m going to impose a few ground rules here that, were I king of the forest, I would write into the law of the land.
- I’ll only update this blog when I think I can add something useful to others.
- I’ll only add entries when I think I’ve written them without spraining the English language too badly.
- If that means the blog is infrequently updated or abandoned altogether, so be it.