Author: jeff

Lessons Learned

After about 5 months, I’ve decided that it’s time to move on to another gig. I’ve learned a few things, and I’m posting them here in the hopes that the lessons might be helpful to other programmers and techies-at-large.

Working in a small business as the sole do-it-all technology person has its unique challenges. It can be very fulfilling to be the sole expert and “enabler,” if that turns you on. But the flip side is that management might not really understand or care that much about their technology. Is there a reasonable budget for what they’re trying to accomplish? Do they understand, at a high level, your projects and how they contribute to the mission? Are technology projects considered a burdensome mystery or something valuable and embraced by the company? Question the reasons why there’s only one tech guy/girl and whether that seems right.

Another thing to assess is whether you can deal with taking over the existing codebase. I’ve taken over other code before with success, retaining what was good and doing clean up as necessary. At this past gig, things looked reasonably tidy at a first glance, but as time progressed, I realized a ton of abstractions weren’t in place, and those that did exist didn’t make sense. Some refactoring might have been interesting to do, but this endeavor wasn’t valued when I proposed it as a project.

Lastly, I think it’s important to be wary of promises about the future. Even with the best of intentions, things change quickly at small businesses. The projects I was initially excited about got perpetually deferred for various reasons, and I found myself preoccupied with doing maintenance code fixes, making cosmetic tweaks, performing server administration, and providing support for third party software (which I really don’t like to do). The company needed these things done, so I did them with as much cheer as I could muster, hoping we’d eventually get to a place where some solid new development could occur (and I could sneak in some refactoring)—that’s what floats my boat. But it became to clear to me that wasn’t going to happen anytime soon.

So that’s that. It’s a shame it didn’t work out, especially since I actually liked everyone I worked with. At least it’s an amicable departure, and I hope to be involved in hiring a replacement who might be a better fit for their current needs than I am.

The new gig? Java. Been catching up on it, since it’s been a few years. Oh, it feels so nice to have package namespaces, real data types, full-featured APIs, and real object-orientedness again. Like coming home.

The Small Business Subconscious

Small businesses can be challenging places to work. You often have to make do with few resources, play several roles at once, and be flexible enough to deal with loose/nonexistent company organization. If everything magically clicks, as it sometimes does, it can be a beautiful thing. But more often than not, that simply doesn’t happen.

As I talked about this with friends who have had similar experiences, they observed that there’s often a common mistake made in small businesses: since every employee is precious, the organization tries to extract as much value as possible by encouraging everyone to contribute in as many ways as possible. It bills itself as a democracy, as an environment that genuinely listens to its employees.

The problem, of course, is that when people aren’t in sync about the mission, or about specific project goals, you end up with a frustrating mess of conflicting directions. The business (somewhat desperately?) tries to latch onto everything at once, and there’s a lack of decisiveness in moving forward. Projects get fragmented. People believe they’re collaborating but they’re actually not. Confusion ensues. Little gets done.

Leadership is even more key in small businesses than in larger ones, I’d wager. Because if you have few resources, you need to choose your projects very carefully, dedicate resources accordingly, and make absolutely sure they go to completion quickly. There’s not much room for failure. But instead, small businesses seem prone to being wishy-washy. The insidious and tragic aspect of this is that when projects move at a snail’s pace or even fail, the accountability falls back on the individuals. Because management failed to lead, it can remain blame-free. It’s a formula for endless frustration.

In this unfortunate strategy, the small business is structured like the subconscious and its conflicts. Its desire is vague and repressed, and though seemingly absent, it’s actually very much the motive force for its existence. Like a human being, the small business can’t decide upon its identity, which remains in flux. And just like a human being, this repressed desire can lash out violently when it isn’t fulfilled.

“It Works”

This blog post, “The Worst Thing You Can Say About Software Is That It Works,” written by one Kenny Tilton, is pretty hilarious. This is the most beautiful thing I’ve read in a while:

if a pile of code does not work it is not software, we’ll talk about its merit when it works, OK? Therefore to say software works is to say nothing. Therefore anything substantive one can say about software is better than to say it works.

Reading this triggered flashbacks and PTSD. I’d mentioned to a manager recently that I wanted some time to do some badly needed refactoring. My explanation of why was met with a pause, then, “Let me get this straight. You want time to take something that already works, reorganize it, possibly break things, and we wouldn’t have anything new to even show for it?”

That last part was wrong–the value added comes from maintainability and extensibility, but I couldn’t get him to really grasp those ideas. He’s not a technology person. For all he knew, maybe this was an elaborate ruse on my part to be left undisturbed while I surfed porn at my desk for a few weeks.

I work in a very small shop with all non-technology people, so this sort of thing happens a lot. It’s frustrating. It’s sort of nice to know I’m not alone in encountering this mindset. But man… if even the fellow programmer in Kenny’s story doesn’t get it, I’m not sure there’s much hope for the rest of the world.

A Quick Observation

For some potential upcoming work, I’ve been catching up on the changes made to Java over the last few years, and exploring the popular frameworks and libraries now in use.

Folks on reddit.com harshly criticize the bloat, unnecessary complexity, and huge runtime requirements for Java. They have their points. But I have to say, having worked on perl and PHP lately, where good code organization is the exception and not the norm, looking at Java again is a very welcome change.

The APIs for stuff like Servlets, Faces, EJBs, and Hibernate may be difficult to learn and remember, but at the very least, I find I always know where to look for something, and it’s usually where I expect to find it. In my book, over-abstraction is the lesser evil compared to not enough.

EAcceleratorCacheFunction = Cache_Lite_Function + EAccelerator

It’s pretty much all in the title. In a nutshell, EAcceleratorCacheFunction is a “memoizing” cache class for PHP that uses shared memory for storage. It is mostly compatible with Cache_Lite and Cache_Lite_Function.

Just like Cache_Lite_Function, it supports per-cache-object lifetime values, instead of specifying the lifetime of an item at the time you store it. This lets you dynamically change the lifetime of the cache. For example, if system load goes up and you don’t mind serving sightly older content instead of regenerating it:

$load = sys_getloadavg();
// use 5 min avg (ignore momentary spikes)
if($load[1] >= 6) {
    $lifetime = 900; # 15 min
} elseif($load[1] >= 3) {
    $lifetime = 600; # 10 min
} else {
    $lifetime = 300; # 5 min
}
$cache = new EAcceleratorCacheFunction(array('lifeTime' => $lifetime));
$cache->call('make_page');

I wrote EAcceleratorCacheFunction as a drop-in replacement for Cache_Lite_Function. On a virtual private server, doing cache reads/writes from memory instead of disk has made a noticeable difference in performance; it helps tremendously that the database has to contend with less disk I/O.