Be a Go Getter

One of the biggest barriers to advancement for a lot of smart, hard working people is the "Does not show initiative" knock or some variation on the same theme.  You would not believe how many times I've been in discussions about who's ready for a promotion and heard something like "Joe does a great job at whatever I tell him to do, but only what I tell him to do" this is the kiss of death because we don't want to tell everybody what to do.

This might be a great surprise to many because from the trenches we feel micromanaged and thwarted in our attempts to make the great improvements we know we could make if only we were allowed.  It's a conundrum - I admit it.

How do you show you're a "Go Getter" ready for advancement while being micromanaged and thwarted by evil Pointy Haired Bosses that cannot code their way out of an open grocery bag - such as myself.

Well it's simple really.  Do the small stuff for yourself or for the PHB of your choice.  For instance if I say "let me get with Don and get back to you with an answer" you say "I can check with Don and make sure I have everything I need."  This is the perfect response because it takes a task off my plate, and it allows you to get the work done more quickly - not waiting for me or annoying me with constant badgering about did I get with Don yet.  Btw the badgering thing will just makes you look like a high maintenance pain in the ass.  I do not want to be reminded of my status as a bottleneck...  

The scenario above is just the starting point of an upward spiral of Go Getter goodness.  Now you are the focal point for the task with Don too - he's likely to be just another PHB and might say "Let me get with Tim and I'll get back to you"  For the life of me I do not understand why middle managers so often turn themselves into Gofors.  Anyway, same thing, tell Don you can get with Tim directly and that you'll keep Don in the loop if he wants.

So at this point you've helped two managers without doing any more work than you would already be doing.  You've made life better for you and Tim because you guys don't have to wait for PHBs to communicate.  And you've made it much easier to iterate through possible solutions with Tim - if that's applicable.

Make this little technique a habit and you'll get more interesting assignments, managers will start to listen to your ideas because they'll know that you are not just thinking of stuff for them to do, and when it comes time to select somebody for promotion you are way more likely be on the list.  Get on the list often enough and you'll get the nod.

Thanks for reading - Mike

A dozen things Deployment Scripts must do

Just like the barefoot kids of the local cobbler I find the installation of many software packages ironic and painful.  Lately I've been talking, a lot, to development managers about getting their deployments scripted and to business people about why Fast, Easy, Reliable deployments are important to them.

Strangely, there seems to be a real lack of understanding on the part of developers about what a build script should do.  I blame IDEs for allowing developers to mostly ignore how things get built and deployed - but I could be wrong.

Anyway,  I've written a list of generic requirements for an automated deployment and this seems to have helped several folks focus their efforts so I thought I would share.  I have gotten some feedback that this list is 'pie in the sky' but I reject that while allowing that some of these things are not all that easy.

An automated deployment should:

1. Start with a single package.
   
2. Reliably put the target environment into a known state.
   
3. Ensure that required disk space is available.
   
4. Save anything needed for rollback.
   
5. Place all files where they belong.
   
6. Register anything that needs to be registered.
   
7. Configure anything that needs to be configured.
   
8. Start everything that needs to be started.
   
9. Validate the state of the application.
   
10. Validate connectivity to all required resources such as databases.
    
11. Report Success or failure and the name of the artifact you have deployed.
    
12. Log all relevant deployment activities.
    

Starting with a single package is important because it's a lot easier and less error prone to move one jar file than a jar file, a couple of properties files, a config.xml etc.  Plus you can give the package a name and store it someplace for later.

By "Reliably put the target environment in a known state" I mean just that.  If you need to shut down an application server you should also search for and kill any hung processes.  If there are status flags, set them to the correct value; basically clean the kitchen before you start cooking.

Nobody wants to get part way through a deployment just to run out of disk.  Check it first.  This is a no-brainer, but often overlooked.

Save your old stuff so you can drop back and punt if needed.  I would urge you to save it into a single package just like the one you're deploying.  I don't think you should rely on going back to the old package as there may be required changes in the current environment.  Those changes should have been the result of a proper deployment, but stuff happens...

Place your files.  I usually call this sprinkling - the deal is that your script needs to put every file where it belongs, using an appropriate path reference.  If it is always going to be the same in relation to the root directory, I like fully qualified path names.  Otherwise I like paths names relative to the installation directory - hopefully all within the installation directory.

Register things that are registered.  I don't know what you might be registering, but get it done here.  Also, start from scratch each time.  If you rely on something already being there, at some point it won't be, so trust nothing. 

Configure things that need to be configured - whatever they are - same as above, start from scratch.  Rather than sending a deltas for a config.xml send the whole (version controlled) file with the contents you want.

Start everything up.  Do this in the script rather than expecting the guy doing the deployment to do it manually.  There's no telling how many hours of otherwise useful human activity have been squandered on troubleshooting just to find that something did not get started when it should have.

Having started everything, go look to see that it is really running.  Seems simple because it is.

Validate connectivity.  If you need it for production make sure you can talk to it and that it answers.  This does not have to be complex, a simple select statement, ping or whatever makes sense for the end point you need.

When something is completed, say so, when something fails, make some noise.  Let the poor guy doing this in the middle of the night know what's going on.  Also, reiterate what version has just been deployed; I have seen people go through a long deployment and troubleshooting session just to find that they deployed the stuff from the previous release.

Build a log as you go.  Tell me when each thing starts and stops and what you did.  Do not dump a bunch of useless noise in the log though.  It should read like a detective's notebook.  

• 22:17 Copied Blahblah1.2.jar to...
  
• 22:20 Change directory to /user/loc...
• 22:20 Executed jar - xf...

Above all put yourself in the shoes of somebody that has to deploy your app along with 20 others, in the middle of the night, while taking calls from people that want status, and trying to grab a bite to eat.

Thanks for reading - Mike

Has Google lost the cool?

I really like my Google stuff.  Blogger, Gmail, Groups, Picasa, Maps etc. etc. etc.  

So why on earth would I be concerned about Google losing the cool factor?  Well at home I run Ubuntu - the first little warning for me was that Picasa on Linux is a wine app.  It offended my sensibilities some, but they had at least made a good installer and it was easy for me - I don't remember the details but it's on my desktop and works so it must have been easy, or I would have pissed and moaned back then.  

They have kinda pissed me off with Chrome.  I mean sure it renders quick and has the cool, visual thing about where I go, I can just click the x for a new tab, and the interface is super clean.  But Google provides no help with a Linux or OSX version.  I went to the trouble of installing Crossover Chromium - a good effort but even CodeWeavers knows it not very good.  So now, like some street corner crack dealer, Google has  given me a taste of the new browser drug and ruined me for Firefox - but I gotta run windows?

For most companies I would not care, but Google started off so cool and they've hired all sorts of smart OSS guys that are presumably Linux and Mac users.  Why then are new Google applications targeted so relentlessly at Windows?  I know that's an overstatement but only by a bit.  Is it really so hard to make the cool stuff cross platform?  Do the non-windows users of the world really mean so little to Google that they don't even bother to give us a semi-elegant hack anymore?

Has Google already gone lame and big business on us?  Do Guido, Stevie, and so many others need to look for the next cool place to work - are they even vested yet?  I hope I get some spam from Google before the end of the week saying all their stuff is available for OSX, Linux (in Deb and RPM) as well as windows.  They could even blow a little smoke up my skirt about how cool they still are.  While they're at it maybe they could update the spell checker in Blogger.

Thanks for reading my rant - Mike

Movin' on up

It's late September and I really should be back at school - but that was nearly thirty years back for me and the boat has sailed. So late September or early October just means review time for me and the folks that I keep amused.

Top questions this quarter;

How do I move up?
When do I get a promotion?
Do I get a raise for attaining this certificate, degree, tenure?

It's got me thinking a lot about who moves up, who doesn't, and why. Or at least I'm thinking about who I want to help and who I don't care so much about helping. So here are some attributes in no particular order:

Focus more on making my life better. I don't mean kiss my ass or pick up my cleaning. I mean get better at your job so I can deliver good news in meetings with my boss.

Focus more on making your teammates lives better. Come up with, and share, better ways of accomplishing the mission. Cross train in their job so you can back them up when needed. Smile instead of frown. Acknowledge their value to the team and help them get better too. Give credit whenever you can - it makes you look better and builds trust.

Focus on making our customers happy and comfortable. Our customer is anybody we deal with outside the team - even the folks who service our requests. Be polite, humble, and easy to deal with even when the customer is wrong or is acting like an ass. I'll step in during those occasions and get things straightened out for you.

Get passionate about what you do, or find out what already turns you on and do more of that. Nothing is more frustrating to me than a smart person who just does what I tell them to do. I don't have the time, or inclination to tell you everything - show some initiative. If what you want to do is in a different area of the company I'll help you get there, if I believe your story. It's better though if you're excited about the job you have and want to make improvements there.

Think big and persevere. It can be frustrating because organizations resist change with more vigor than they do anything else; think big anyway and keep pushing forward a fraction of a step at a time toward those goals; it always takes longer than we want and still happens faster than we realized if we just keep moving.

Do the above and quit worrying about your career progression so much. The people that do this stuff have me working on their career even if they don't know it.

Thanks for reading - Mike

Why Masters Matter

So I've been getting beat up a bit on the extremeprogramming mailing list. Part of the issue is that I often don't know what the hell I'm talking about; even when I do I don't express it as well as I should.

I post questions or statements about what I want to try, and I get back responses that I'm trying the wrong thing or going about it in the wrong way. And that what I need is to hire a coach, get some assessment, and have some more conversations.

I have to admit it was getting on my nerves. I can read, the practices are not super complex - what the hell?

Anyway, on the theory that if a lot of people that have been in the field are saying the same thing and seem to agree with each other, I should listen, I called Ron Jeffries to talk for a bit this morning. We talked about some of the things I had posted and some other stuff but rather than getting any kind of prescription I got nuggets of wisdom - some of which have been percolating all day.

As an example I had the idea that I should require a set of XP practices and provide training in those practices. On the list I got a lot of feedback that requiring practices is a horrible idea. I was confused by this - I'm talking about having people do the stuff you guys say work and I'm getting a bunch of noise back - again, what the hell? Am I supposed to just hope that people will do the right thing? Who's gonna feed my kids when I get fired?

Ron cleared the whole thing up for me in like one paragraph of talking. I'm paraphrasing here but he essentially said that I could require running software that passes my tests. In other writings he calls that Running Tested Features (RTF.) Anyway, having a requirement for RTF, developers might look for easier ways to satisfy the requirement and the proverbial we could suggest practices and provide training/coaching.

Ding Ding Ding - that makes perfect sense to me. It clears up many of the responses I got on the list, and it completely illustrates why I should indeed sit at the feet of the masters. I could perfect every practice and make people do them, but still not get the RTF I need.

So now I'm going back to see about shaking budget loose to bring Ron and Chet in for a few days of master wisdom - wish me luck

Thanks for reading - Mike

Story size - and Motorcycle rides

I ride bikes in three distinct landscapes, and where I'm riding has a lot to do with how I approach the activity.

On a road race track I know the profile of every corner, the available traction, and all the landmarks. I can fully commit to my line and string the curves together so that the exit from one corner sets me up for the entrance to the next. I'm going to see the same sets of corners every minute or two, I know exactly what I'm going to do well in advance, and I can think in big chunks of track - I have to do this to be fast. I can clearly see where I am going and plan every action along the way before I even get on the bike. Then it's just a matter of improving my execution through practice and repetition.

A semi-equivalent software development system is making cookie cutter websites with branding. The customer just chooses from a menu of re-usable functionality and most of the discussion revolves around the branding elements. The analogy with track riding breaks down though because riding a motorcycle at speed around a race track is just a bit more engaging then churning out cookie cutter websites.

Street riding - even on a familiar route is a whole different game. There are cars doing all sorts of seemingly random stuff, gravel on the road that was clean yesterday, driveways, pedestrians, and who knows what else. On the street it makes no sense to commit all your traction to a corner, or to be too attached to the exact path of travel too far in advance. You want to look a far ahead as possible, watching for the telltale signs of trouble so you can adapt your approach to the changing conditions.

This is the sort of environment that most corporate software development takes place in. There are regulatory changes, market conditions, new internal customers with their own ideas for improving things, and always budget constraints. The rules are very similar to riding in traffic. You know where you want to end up and you know pretty much what route to take but you must be ready to adapt to the changing conditions.

Finally there is off road riding. This is incredibly interesting and challenging. Often I don't know where the next bit of trail is going, or what the surface will be like. I can only plan very short intervals of the future and even those plans are subject to change with very little notice when the trail takes an unexpected turn ,or traction disappears in the middle of a challenging hill. I fall down a lot when riding offroad.

New product development is a lot like riding off road - you're always inventing something new and there's no telling where you might be even in the near future. It's also very interesting, a lot of fun, and you might fall down from time to time.

It is exceedingly rare that I fall down on the track or the street and falling in either of those circumstances can be very expensive in financial and human terms because the typical track or street bike is very sophisticated and street bikes in particular are heavy. Off road I fall frequently, and really appreciate the light weight, easy maneuverability, and durability of my dual sport bike. It turns out that the lightweight and simplicity of the dual sport are great on the track and street too.

Agility makes riding on the track more pleasant by requiring less effort to execute my plan, it makes street riding safer by making it almost effortless to adjust to the changes I see ahead, and it's a whole lot easier to pick up when I fall offroad. Similarly, I think agile processes make life more pleasant, safer, and resilient in any area of software development too.

Thanks for reading - Mike

A little slow on the uptake

Sometimes we just want to invent stuff for ourselves. We often pay lip service to the idea of learning from the mistakes of others and profiting from lessons learned and work in the can; we might even believe it. But still we do our own thing, make our own mistakes and come to many of the same conclusions of those that have come before.

Over the last few weeks it has really come home to me how much I tend to think I am at least as smart as all those other guys, and that I can surely figure things out for myself. I still think it's true, but why would anybody want to live without delusions - especially delusions of grandeur?

Earlier in the year I wrote some articles on agile development and how great I think it is to be agile, with some examples of how things might be done. You can find them on my old blog if you care to.

The thing is though, I almost completely ignored extreme programming(XP) and Scrum.

XP because when Kent Beck's book first came out, the whole process just seemed kind of flaky and inappropriate for the kind of large organizations I was working in. I could see myself talking to an auditor and handing over stacks of 3x5 cards when asked for system requirements - as if. I was also somewhat turned off by the idea of pair programming - I do not want to sit shoulder to shoulder with anybody all day, not having to is one of the perks of IT work.

Scum because the name is asthetically unattractive, and at first glance it looks like a ripoff of XP without the good engineering practices. What's the point of that?

I was stupid. I should have been paying better attention because over the years while I've been thinking about process improvement, reducing the signal to noise ratio of system docs, and removing friction from people's lives; these guys have too. And they've been doing it in all sorts of settings as consultants and coaches. XP has matured, lessons have been learned, and practices have been improved. They've even done some studies showing gains from pair programming and TDD. It also turns out that Scrum is more than just a subset of XP - though the name still leaves a lot on the table of asthetics if you ask me.

A few weeks back I was invited to join a team of folks at work to explore moving to an iterative development process. We had bought a smaller company that had recently adopted Scrum and did not/does not want to go back. That gave me an opportunity to really look at Scrum which quickly led me to revisit XP as well.

I have been in a total immersion self study course - reading the websites, comparing the variations, joining the mailing lists to ask questions, and watching a bunch of video presentations on infoQ from many of the guys that started XP and Scrum. It turns out that I agree with almost everything with the possible exception of the sales pitch that includes things like 'add joy to the workplace.'

Not that I'm against creating a great place to work; but even I - raised mostly in the west by hippies - can see that the guys writing the checks are not all that concerned, even if they should be. I would rather see a sales pitch that talks about ROI and behaviors that lead to greater ROI in the long term. We all know that happy porogrammers will be productive so let's just talk about the corporate behaviors that lead to happy programmers in terms of the benefit to the bottom line, and leave the happiness argument out of it.

If, like me, you've been kinda ignoring XP and Scrum as something nice for small teams of folks that won't eat a good bar-b-que sandwich with a side of slaw; reconsider. Get out there and watch the videos, read the websites, subscribe to the mailing lists, and ask a lot of questions. I don't think we can tweak the old waterfall (dinosaur) method enough to survive the onslaught of the furry little XP critters.

Thanks for reading - Mike