Code Wizards’ Blog

quick post: I think I need to reply to Computer Weekly’s blog entry - The IT Professional’s Survival Guide.  I think it’s heading in the right direction but got sent off at a terrible tangent at some point…
Firstly, the most important thing is not to “flatter“, or understand “where you fit in” it’s simply to learn how to communicate properly.  Many IT staff are proud of their logical outlook on life and rejoice in “simple” answers.

For example, years ago I was working with support engineers, a “request for change” ticket came in saying “can you help me organise my files better?” to which the reply was “no”.  That’s neither helpful, nor useful (even if it may be correct in some cases), and it’s not answering what the user wants and needs.  People remember good service and those that try and help them (and some evolutionary biologists claim that we “like” to help others - even if the computer business is a good model of the reverse!).

What the engineer should have done was simply ask for more specifics, it takes 10 minutes to do so, and even if you can’t help you can point them in the right direction (”sorry, I think you need to speak to Ted about this - he’s the head of Business Process re-engineering”).  It costs nothing and you’ll have a better relationship with the non-IT staff.

Secondly, “Dress like your peers” - I disagree almost as strongly.  As a young man (with hair) I was often sent to customer sites and heard the users say “thank god, he looks like a freak: he must be good” (not every time, but often).  Non-IT staff expect computer people to be nerdy and geeky, and often the nerdier and geekier they look, the better they must be.  In contrast, even IT staff have probably been concerned when a beautifully suited and presented individual comes in as a star “consultant” - it just doesn’t fit the mold.

Also, we’ve all seen engineers who wear a suit and yet look worse than if they’re in a bin-bag.

So, am I advocating looking terrible all day and wearing T-shirts with expletives on them?  No, really no.  But, dress to match your style and finesse and remember it’s not London geek fashion week - nobody will love you for a T-Shirt that says “all users are idiots” regardless of how much Geek kudos it grants you.

lastly, understand the business you’re in (regardless of your position).  When you’re in a marketing department’s IT team then ensure you understand what they’re marketing, how they do things and, at the least, the outline business processes.  That way when a user contacts you then you ask sensible questions related to what they do, they’ll respect you for it, and you’ll achieve more.

You’ll be amazed, even if you’re not a programmer (then you have no excuse for knowing what they do and you should hang your head in shame and make for the door with your head bowed) and you’re doing server support then the setup of the machines is still related to the business itself.  Even for a support engineer there are places where you can help that business run (or stop that business running better) by your actions: there’s no point you pushing windows OS if none of the software runs on it, but if the users need a document store with some workflow then you can ask if it makes sense to include Windows Sharepoint or IBM Portal or similar as part of the standard build, or alternately if the machines never do any high transaction work/high IO then why is the business paying out for RAID1+0 local disk arrays when it could be using a (relatively) low latency SAN solution and sharing disk between all the machines.

In summary, IT does have a place in businesses, but arrogance, laziness and ignorance of IT staff doesn’t.  Do yourself a favour, find a nice big mirror and take a long hard critical look at yourself, it’ll be not just good for your current job/contract/assignment, but it’ll help your work ethic (and your job satisfaction) more in the longer run too.

One of the jobs that Code Wizards often gets is to help a software project that’s in trouble, and there’s a pretty standard list of things that we do each time to establish and baseline and see what we can do to help.

Identify the movers and shakers - who’s the head developer?  who handles the builds?  who developed the list of controls and processes (note: these don’t have to be documented, they can be anecdotal: “oh, Bob always does the builds then runs through a quick test before deploying it himself”)

1. How long has the project been running?  How long has it been in crisis?
2. How experienced are the people on the project?  Have they always worked at this location or a lot of places?  Have they got formal training?
3. How are requirements handled?
4. What’s the technical infrastructure like?  Is it all based around a windows SMB share where everybody deposits their code? Is there a bug ticketing system?  Are bugs handled by an Excel spreadsheet?
5. What’s the subject of the Project?  From a personal perspective if you were asked to give a timescale for delivery (independent of what you see at the project) would it match those that the project has got or has atleast asked the business for?
6. Is there a process for testing (at the Unit, Functional and Integration testing levels)?   How is User Acceptance Testing (UAT) handled?  How are user bugs and requests for change documented, triaged and executed?

By this point you should have a good idea of what the project is all about, what it’s trying to achieve, what’s in place and who’s in place.  So it’s time to put it all together.

At this point your opinion won’t be perfect and it’s important to remember that, you’ve seen a small slice of the project and you’ve got a flavour and opinions but few definitive facts.  I’ve seen bolshy and over-confident engineers examine projects and immediately announce who should be fired and promoted, and provide “concrete” steps that will “guarantee success”.  Ignore them, they’re the snake-oil salesmen of the 21st century and they’re often dangerous (you can often identify these people as their CV/Resumes read like a Hagiography and they’ve never worked on a project that’s been canned).

First of all attack the basics; no requirements or documentation? then insist that some are put together regardless of whether you’re fed some line about this being “extreme” and/or “very Agile”.  Input document packs should represent the basics: a mission statement (what you want to achieve), a general outline of strategy (how you’re going to achieve the mission), and an outline of technical aspects (what technologies are in use, why they were chosen and what’s forbidden).

Then look at configuration management and software management.  In this day and age there is no excuse for not using source control and a ticketing system, and I mean that, there are NO reasons not to have those things in place.  You’ll probably find that various people (including lazy developers) resent this idea, force it through anyway - i’ve never seen a project that runs better without source control and ticketing systems.

If there isn’t a specific requirement for source control then pick something that’ll work and is free (free is always easier to get into businesses than paid for software in our experience).  If most of the source code is text then you can’t go wrong with Subversion, it’s got a good UI for Windows (TortoiseSVN) it’s very similar to CVS and it’ll integrate directly into a software management tool called “TRAC“.  If you’re working in Visual Studio then go for Team System - it’s pretty good and it integrates into Visual Studio which will make the developers job easier.
TRAC should be an easy sell to the client, it’s free, integrates with Subversion (aka SVN) and reads the changelog, it’s open and extensible and includes a wiki that you can use for documentation.  OK it doesn’t do everything, but it does most things, and it does it well and doesn’t encumber the developers.  But I’ll blog more about TRAC in future.

Next establish basic processes and document the original and your revised versions (nobody else is going to do this for you - so put some headphones on and get your head down and get a basic set documented).  This gives you a way you can show people why they’re different and what the benefits are (if you’re in TRAC then do this in a nice diagram and put the new processes on the first page of the wiki).

Then start creating tickets for functional implementation and bugs and start showing how you can assign them and have them worked on.

Lastly, present what you’ve done to a mixed audience of the business owners of the project, the project and programme managers, testers, developers and analysts, and get ready to be flamed, heckled, insulted and generally disliked.

The truth is that few of us like being criticised, especially when it’s from an outsider so it’s not going to be an easy ride.  You’ll probably find acceptance comes from the business lead (who probably hired you to look at their project), then the programme manager, project manager, testers, team leads and managers, then the developers.  It’s a fair chance that the developer leads (aka “Corncobs” according to Anti-Patterns) will never accept the changes unless you present the ideas as being partly their idea, so do this if it makes your life easier.

Before disengaging you’ll need to help them run the new processes and tools and ensure that everybody is keeping to the requirements of their roles (are analysts generating requirements now? are the team leads ensuring that developers are always checking in with defined ticket numbers?  are testers entering and tracking their bug tickets?  are managers handling bug/function ticket triage and assignment?).

You’re probably thinking, ok those are good points, but why does it make sense to use an outside party to do this?  Well the reason is simple: you need somebody without affiliation to anybody in the project, you need somebody who doesn’t mind being disliked and asking difficult questions, and lastly you’re better off if that person can come in and do the work then leave - so then the team can act like it was all their idea anyway and collectively bond while moaning about the person who came in about the work.

Do teams ever welcome you, acknowledge the things that are wrong and help you remedy them?  Yes, of course but it’s few and far between and those are the managers, leads, developers, testers, and analysts that you should think of the next time you need to build a team to develop software as they’re worth their weight in gold.
Good Luck!