Business Cliches

Thankfully someone took the time to put this list together:
http://www.clichesite.com/category_results.asp?which=business

I'm happy to say I only use about a third of them on a regular basis. Think I'll throw in "A house divided against itself cannot stand!" as a dramatic interjection in our next meeting... see how that one goes over.

Make Your Junior Developer Interviewees Cry

Long ago I was asked (while interviewing for my first development job) to implement the following panic-inducing algorithm in the course of an hour or so during an interview (i.e., sit down at a computer and get it to work - not just whiteboard + handwaving):

For an arbitrary arithmetic expression string with nested parentheses, parse it and compute the answer. (Note: Google has this built in to their search engine interface - if you type "((2 + 6) / 4) * .01" it will give you the correct answer. Wouldn't be surprised if they ask this programming question to interviewees as well.)

It's a good test of whether or not you've got someone who's a very promising candidate or not, especially if they'll be doing something in the area of compilers/interpreters. Tests string manipulation, state, recursion (probably they'll try that approach) and is long enough to get a feel for their style.

Wiki Day

Good developers are always interested in learning new technologies, and management usually wants to find inexpensive ways to keep them (which means keep them happy). It's well known that Google allows developers one day a week to pursue whatever side (tech) project they want, and that they've been voted best company to work for in the US. How about a variant of this for the not so well endowed (but aspiring) software company: a wiki/blog day (or if need be, a half-day) each week where developers pick a (potentially) relevant technical topic they'd like to know more about, read about it online and post a few dozen facts / thoughts about it on an internal wiki (to be reviewed by their peers/manager). Might not be great for the short term, but seems like it would be a win in the medium-long term for morale, technical freshness of the team. Not to mention the new product ideas it might stir up...

db4o - What a Concept

Neward gives a great summary of the long RDBMS slog so many developers have had to deal with, and what sounds like a very promising answer (db4o, which I haven't tried out yet):

http://theserversidecom.bitpipe.com/detail/RES/1178562676_577.html?src=wc_atssc_sitepost_05_08_07_c&li=53472

I haven't been particularly fond of the QL variants / query object trees one has to create in Java when using, for example, Hibernate. Wonderfully, db4o apparently lets you code 'native queries,' which are basically anonymous inner classes with a match method, where your query matching logic is simply a normal java expression on whatever objects are relevant to the query. So QL statements like "select blah from person p where name = ? and age > ?" becomes something like:

match (Person p) {
return (p.getName().equals("name to match") && p.getAge () > 21);
}

The Power Of One (or Two)

I'm surprised that software managers do not take (more) advantage of the fact that on most software teams, one or two members do the work of several moderately good developers each. I believe they know about this, but the salary band for developers remains relatively narrow - why? If you can pay 1.2 times the competitive salary rate and get a top notch person who does 2-3+ times the work of a single developer, it's clearly worth it. Similarly, with some extra effort you can find quite smart (though not as experienced - think graduates from good universities with 3.7+ GPAs) developers for significantly less than competitive rates for experienced developers. When they're directed by the strong technical leadership of the top notch experienced guys/gals, chances are good they'll produce the work of a much more experienced developers in 6 months. You'll pay .6 times going rates for 5+ year experienced developers and get junior developers who'll be nearly as productive with the right leadership, especially given their added motivation to prove themselves early in their careers.

Kudos To Netvibes...

... for making a Web 2.0 site I really do use every day. As Andrew Sullivan pointed it, it's nice to be able to surf half the web all at once on a single page (well, half the headlines anyway). And it doesn't even crash all that much despite its pretty sophisticated dragon droppings and myriad configurable settings and so on.

Bug Tracking Wish List

Most likely this is available in some bug tracking systems, but I haven't seen it (used) in ours (TestTrack Pro), nor at other companies I've worked at. The concept is automatic escalation of bug priority over time, and it seems like it should be the default behavior to me. Think about it - if someone files a low priority bug, it still should get done eventually - it should not be endlessly bumped / kicked down the road for higher priority bugs. Over time, its priority should be raised automatically to the point where the system finally (in effect) says "It's been TWO YEARS FOR THIS ONE, ARE WE GOING TO FIX IT, OR WHAT?"

Profiling - Don't (Over)do It

When in the course of a large deployment of an enterprise application, I've seen many a developer quick to break out their favorite profiling tools (e.g., OptimizeIt, JProfiler, etc.) and 'get to the bottom' of the performance problems. And they do get to the bottom, often way too far down there (think seeing only those proverbial trees as opposed to the forest). The problem is that all too often, this results in some low-level slight optimization of some oft-called function, not a real examination of higher level architectural issues that could really speed things up if fixed. Shaving a millionth of a second off of a few functions called tens of thousands of times is often not particularly helpful. Restructuring code to cache significantly more in memory that was previously in DB, for example, probably will be (although of course brings with it various irritating issues related to caching). But you will not get such suggestions of restructing from profilers of course. Very often in enterprise apps, the issue is not computing a value or concatenating some long string or what-have-you, it's too many roundtrips to someplace else far, far away.