Wednesday, January 31, 2007

Handling Slippery Managers

This is something I've wanted to write about for a while. I hear too many horror stories from great programmers around getting screwed by office politics: a project getting pulled; being strong-armed into bad technology decisions; forced to stay late-nights while the boss take 100% of the credit. So, this post is the first in a series about simple things programmers can do to deal with office politics.

Get it in writing. If you are promised by your manager (or anyone) something - anything - get it in writing before you commit. Especially important things: a better job title, the choice of the next project's technology, more money, or deciding on the new coffee flavor in the break room. Email is a natural choice for most developers, but if your boss will only scrawl something on paper, tuck it away - hopefully you'll never have to use it. It should go without saying that you should keep all of your emails - back them up or print them.

Sidebar: Anyone who knows me understands that I'm kind of a poker freak (president and founder of the Purdue Poker Club, 1999-2002!), so I tend to think of the world in poker terms, such as bluffing and odds. It's a useful metric to measure the world, especially when dealing with people in office situations, since their body-language will tell you a lot about whether they are on the up-and-up or full of shit. I do not tend to - as a rule - trust managers who refuse to commit to anything in writing.

If you ask repeatedly and managers find ways out of writing their promises down, there are good odds that they have no intention of keeping any promises. So I devised this trick to get around those shady bastards that only make verbal commitments: keep meeting minutes (on paper if need be), and email it back to them. Something like this:

Dear Big Boss Man:

I took the liberty of keeping track of our meeting's minutes:

12:01 - begin meeting
12:05 - J.P. asked about job title
12:06 - B.B.M. mentioned giving J.P. Senior Architect role at next review
12:10 - B.B.M. asked about project status
12:15 - J.P explained status
12:16 - B.B.M. talks about football
12:28 - end meeting

Joe Programmer

Now in three months when you are passed over for that promotion, shoot this puppy back - and to his boss, if need be. Managers tend to be fairly sensitive about 1) being sued, or 2) their image. Keeping meticulous notes lets them know you know how to play the game, sometimes that's enough. Otherwise, its still good fodder for your lawyer.

The converse of the previous suggestion is to avoid agreeing to anything in writing that you are not comfortable honoring - even if you are, at least avoid being bitten by some unforeseen future circumstances. This is a harder habit to break for many geeks, since we so often converse via email without a second thought. Get used to it. If your manager sends you an email like this:

Hey Buddy:

Just wanted to get an estimate on that new project to write a new operating system from scratch. What do you think... two weeks?

Big Boss Man

Do not reply via email! Call him/her on the phone, go chat in the boss's office. It's a pretty simple thing, and it may save you loads of heartache in the future, as the boss waves the email over your head as though it were a binding contract (it does not matter that it's not... there is no doubt that you agreed to it).

As a final note, don't take these suggestions to be of malicious intent. I think that group environments work best when everyone is trustworthy and apolitical. However, there is nothing wrong with being organized... at the very least it keeps your thoughts and history precise. It only takes one political wonk to ruin it for everyone - so it never hurts to protect yourself.

Friday, January 26, 2007

Code Te Ching - Verse 1

Code that is coded is not Code.
Grammar can own no variables.

Having no grammar, it is the source of conception.
Having grammar, it is the mother of all language.

Empty yourself of language and perceive its subtlety.
Blind yourself by language and see only its manifestations.

These two converge, but have different names.
They are both conception.
        We call them mysterious.

Where they converge the deepest is the gate of true understanding.

Wednesday, January 24, 2007

The KISS Smarmy

The KISS principle has long been a cherished symbol of wisdom - especially for software development. And why wouldn't it be? Avoid complication; make it elegant; be agile; keep it simple, stupid. Any well-laid design can be torn apart with a simple placement those four words. And just in case the victim had any illusions that keeping it simple was not the proper course, they are treated to one final jab: barring simplicity implies their stupidity. The design could have been simpler, if only the designers weren't so dumb.

Keeping with this theme, I have endeavored to create my own list of principles - ones urging my listeners to apply my wisdom under penalty of being called a disparaging name. So read on, Stupid.

The KILL principle:
Keep it Light, Loser. This is a specialization of the KISS principle, which can apply similarly to software development situations (use light frameworks - such as POJOs, loser) or others (keep the social situation light and breezy - or you are a loser).

The KIDD principle:
Keep it Documented, Dickhead. I think this speaks for itself. Only dickheads don't document their code.

The KIAA principle:
Keep it Agile, Asshole. This principle urges the audience to keep to agile methodologies - you can imagine what I think of those who don't.

The KIFF principle:
Keep it Free, Fucker. Free as in opensource. It's always fuckers want to close-source everything. Especially applicable to corporations who use open-source software, but refuse to give anything back to the community. Man oh, man - what a bunch of fuckers.

There are undoubtedly more, but it might stop being funny if I keep going.

Wednesday, January 10, 2007

Windows Maven Menu Options

I hate command-lines. No wait, let me back up... I love command lines because I can automate repetative tasks; but I hate command-lines because I tend to navigate directory structures using a GUI window manager, then have to open a command-line in that location to execute what I want. I have my own hierarchy of needs (eat it, Maslow!). When I do something occasionally, I don't mind having a GUI tool to help me along. When I tend to do the same things often, I script them, and use the command line. When I do something very often (multiple times a day), I find typing too arduous, and so find a way to add it to my right-click menu.

Here is how I added these sweet actions to my windows right-click menu:

First, you have to write the batch script. My script is as follows, in a file named "C:\maven-install.bat"
------------------------------------------------- BEGIN FILE---------------------
@echo off

set MVN="C:\maven-2.1-SNAPSHOT\bin\mvn.bat"
set REMOTEREPO=file://M:\
set REMOTEREPOID=in-house
set VERSION=1.0

if "%1" == "install" if "%~nx2" == "pom.xml" goto pominstall
if "%1" == "install" if "%~x2" == ".jar" goto jarinstall
if "%1" == "deploy" if "%~nx2" == "pom.xml" goto pomdeploy
if "%1" == "deploy" if "%~x2" == ".jar" goto jardeploy

goto end

%MVN% install -f %2\pom.xml

%MVN% install -f %2
goto end

if "%GROUPID%"=="" set GROUPID="%~n2"
%MVN% install:install-file -DgroupId=%GROUPID% -DartifactId=%~n2 -Dversion=%VERSION% -Dpackaging=jar -Dfile=%2
goto end

%MVN% deploy -f %2
goto end

if "%GROUPID%"=="" set GROUPID="%~n2"
%MVN% deploy:deploy-file -DgroupId=%GROUPID% -DartifactId=%~n2 -Dversion=%VERSION% -Dpackaging=jar -Durl=%REMOTEREPO% -DrepositoryId=%REMOTEREPOID% -Dfile=%2
goto end

------------------------------------------------- END FILE---------------------

Set the MVN variable to your mvn.bat location, your remote repo, repo id, etc. The GROUPID variable is the groupId a JAR file should be deployed as. If none is provided, it will use the artifactId, which is just the JAR's filename, sans extension. Notice this script pulls double-duty. Not only does it install or deploy a project on a selected "pom.xml" file, it will also install or deploy any selected "*.jar" file too, with all of the pertanent information supplied. Sure, I could have made the code nicer, but this is an MS batch script we're talking about here... no need to polish this turd.

Next, edit your registry to add the menu items, and the corrosponding actions. You can open regedit, or just put the following into a *.reg file and double-click it.

------------------------------------------------- BEGIN FILE---------------------
Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\*\shell\Maven Install\command]
@="C:\\Windows\\system32\\cmd.exe /T:0A /k C:\\maven-install.bat install \"%1\""

[HKEY_CLASSES_ROOT\*\shell\Maven Deploy\command]
@="C:\\Windows\\system32\\cmd.exe /T:0A /k C:\\maven-install.bat deploy \"%1\""
------------------------------------------------- END FILE---------------------

That's all. If you make any really cool extensions to this little hack, please, oh please, send them my way.

Tuesday, January 9, 2007

Problem de Jour: Personnel

From broken vaccum tubes in days of old to modern day problems of dropped internet connections and lazy programmers - computer development has always been somewhat perilous. Just as computer hardware has evolved, generations of programming languages rise, and system architecture grows more sophisticate, the central problems of software development necessarily change. Where software's largest problem was at one time hardware (as machine portability); with the advent of simple networking the problem became widely architectural; today's modern software development problems fall largely into a single category: personnel. The problem is simply stated as: how can you organize a group of people to optimally focus on solving some business problem? (I use the term "business problem" loosely, including things like research and open source initiatives... whatever your business may be.)

If your organization's brand-new software project still suffers from hardware or architectural problems in this day-and-age, the problem is most likely you, or your bosses, or your developers, or your consultants. This is not to say that machine and architectural problems no longer exist - far from it - but they should not be the focus of any modern day development effort (unless hardware is your business, in which case you are the minority - so stop reading). The reason for this claim is simple: there are too many standards, tools, and pre-packaged architectures for any of this to be a problem. Do you need to write a simple web app with less than 10,000 users? Ruby on Rails. Do you need to connect to a database? Hibernate (Why are you writing ORM by hand?). Is your requirement to manage a large number of connections from several clinets? Enterprise Service Bus. Must your connections be guarenteed? JMS, of which there are several mission-critical implementations. I can go on forever. The accepted importance of standards, APIs, toolkits, design patterns, et al, have all but cleared the field of major architectural problems.

So if architectural problems no longer fill the spotlight, why has my development team been stuck on a single problem for months? Here are a few possibilities, in increasing order of destructiveness: lazy programmers, dishonest consultants, incompetent managers, incomplete or excessive organizational structure.

Lazy programmers. We all know the story: memo from the Boss, all the programmers are pulled from their desks to the Boss's office, the door closes, whereafter the Boss proceeds to explain why the project failed: you all are a bunch of lazy shitheads (perhaps in not-so-many words). If only you worked harder, the current failing project would have been a success. You proceed to explain to him that this was not the case, however. You tell him about the four hours of time you lost yesterday wrestling with a decrepit build-system, and the two days you lost last week when the network was down. What were you supposed to do? If the Boss is a mediocre manager, he will likely accept your tale at face value, and, maybe even extend your deadline. Perhaps you were being honest - perhaps you really did waste days on a broken network. But was there really nothing you could do during that time? Was it really impossible to catch up on some documentation, make some calls, or design some code on a napkin? Did you offer to help the network team to get the service back up? If there was truely nothing that could be done, did you at least read a book? Sure, there is lazy, and then there is fucking-lazy... perhaps you are not at the stage of epithetical prefixes, but to quote a cliché: if you're not part of the solution, you're part of the problem. Take initiative. It's easy, very easy.

Dishonest consultants. These are a personal peeve of mine. Many consultants are very good, mind you, but when you're hired by non-experts to be an under-restricted expert in something, it's human nature to take a little advantage of the situation. This is likely not malicious intent, but something as simple as driving technology decisions to things you already know, or worse yet, to things you want to know. If you find yourself looking at your resume before deciding what technologies to use - rather than what is best to use - you have propogated the sin of resume-driven development. Some consultants, on the other hand, are malicious, and will drain your company dry. I once worked for a company that paid a group of 20 consultants US$10 million in a single year for code that was so awful it was eventually re-written in entirety. But man, oh, man, their website was pretty. Give someone 8 hours, and it will take 8 hours - even if the task only requires 2; give him the keys to the kingdom, and he'll want your daughter too.

Incompetent managers. This group is the worst so far - largely because they are responsible for creating the environment allowing the previous two to thrive. My former boss used to say his job was to make the shit that flows from the top stop before it gets to us. He was a good, buck-stops-here sort of manager. Bad managers let that shit avalanche right down to the developers. I find that the best measuring stick of a manager (and everyone else, for that matter) comes at crunch-time - bad managers tend to call for more meetings. Their Boss wants reports, so they want reports, creating more work for the time-deprived developer. In fact, there are subtle rules to calling meetings involving developers that all software managers should know. Rule 1) Call enough meetings to avoid lazy programmers and dishonest consultants. Make them say what they are working on, and how you can help remove obstacles. Rule 2) Don't call too many meetings. Like Goldilocks, you need to make it just right. How many is the right amount? I don't know, ask your developers (just not zero. Meet once a day - check out something Agile like Scrum). Rule 3) Meetings should never be in the middle of the day - that context switch will break his concentration, making the project take much longer and frustrate the programmer. There is more, but you get the idea. This isn't exactly revolutionary stuff here.

Organizational structure. The echo of the industrial revolution boom can still be heard today, its vestige lives on still in software compnay structures. When making 5 trillion widgets, it's a good thing to have an unwaivering process to ensure that widget #4,143,143,321 is the same as widget #4,143,143,322 and beyond. It's well known problem that software companies run like traditional manufacturing do very poorly, but it intrigues me how often these lessons are forgotten. Let us look at a couple glaring organizational problems:

Contracts and contract-driven process. Like the Agile Manifesto suggests, working software is always better than a solid contract. But organizations still get stuck in the steps of the post-industrial habit of buying and selling: Step 1) find a good supplier. Step 2) negotiate a good timeline and price. Step 3) let them deliver the goods. Software development doesn't work this way for a simple reason: every piece of software is widget #1... and there will never be a widget #2. Once the software is written, that is the deliverable, and has little bearing on a similar project next year. The chance of correctly guessing in advance all of the unknowns in creating the first widget is very low - each project is different, rendering any answers to be very loose guesses. This renders even the most rock-solid contract on shakey ground - and a shakey contract is a useless contract. Contracts can even be binding in a negative way, forcing developers to work on a dead project just because the contract said so (read: Death March). The best software development organizations empower members to self-organize. This is not just so individual members can feel comfortable with their self-made beds, but also the fact of non-duplicatability - just because you did a web app last month for a daycare company's payroll department, doesn't mean it has anything to do with this new daycare company's payroll department web app.

Unnecessary manual process steps. We are software developers. Our job is to make the world a better place by use of software. Yet a disturbing number of development organizations inject manual steps into their development process. My previous job required over a dozen manual steps per project (even small code changes), from calling kickoff meeting (which are generally a good idea, but bear with me) to printing and signing release for everyone involved, to faxing documents to ourselves and saving them in a special version-control environment, to several manual code-promotion steps. Even ignoring the fact that most of the steps were unnecessary, an even larger issue gnawed at me: why can't we just write code, check it in and build/deploy it? We were bound to the rules of ISO and the FDA, but was this a good enough reason? No. The organizational structure created more work than necessary solely because no-one wanted to change it. The sign-offs could have been digital, the promotion system could have been automated, and the meetings could have been virtual. Developers should not spend even 10% of their time doing manual steps - not when we are the ones who, in the end, are most equiped to automate our lives to Nirvana.

Philip Howard (author of The Lost Art of Drawing the Line) noted, every organization, no matter how seemingly large and mindless, can always be changed if someone - anyone - takes the initiative and authority to improve it. Ultimatley organizational problems are really personnel problems, all the way down - and personnel problems are the only real software problems left.