ThoughtFactory.CreateThought() A random collection of thoughts from an easily bored developer

Lip Service

The internet is a fast paced world where the general consensus about what is "cool" can change in instant, and the online software development community is no exception. Recent years have seen movements relating to topics such as craftsmanship, quality, and design spread like wildfire through the tubes, eventually crossing over into the real world in the forms such as books, conference talks and user group meetings.

If consulting companies are good at anything, it's recognising trends and jumping onto band wagons. Many organisations have seen the movements within the development community as opportunities to gain new business, attract employees or quite simply make some cash. Others are staffed by people who are not quite "in the loop" enough to be part of the original movement but still want to be seen as participating even if they don't understand the finer details of what those wacky internet people are talking about. This has seen a large number of IT consulting firms attempting to align themselves with a wide range of topics/buzzwords such as Agile, TDD and SOA.

This alignment process has lead to a rather disturbing trend of companies making bold statements about the "minimum standards" that their teams must adhere to. I use the word "disturbing" for two reasons:

1. The minimum standards are usually ill-conceived or miss the core principles of what the original movement was trying to say
2. When push comes to shove, they are not actually enforceable, leading to uneven application or even complete abandonment of the "standards" dependent on client or project

Consulting firms have been missing the point in an attempt to "me too" the latest trend, so no surprises with the first point; just ask for a definition of Cloud Computing next time you're at an industry conference to see that in action.Still, in some cases there is still some value to be gained out of the application of the misinterpreted principle. After all, the Code Reviews touted by a firm may be nothing more than a soulless checklist designed to cover behinds rather than improve code quality, but at least it's a start.

Now, setting aside that what these companies are trying to implement isn't all that great in the first place, it's still amusing that there seems to be a huge lack of understanding around the  meaning of the word "minimum". If you're having trouble, let me Google that for you. If you have a set of standards, then say that a certain set of those standards is the minimum that you will apply then those are the smallest set of standards that must be met. In fact, it should mean that a project crisis meeting is held or intervention is required if you don't actually meet those standards. If a standard is not enforceable, or you don't apply them in specific circumstances then it is not a part of your minimum standards; you may wish to refer to it as a "nice to have".

I have a sneaking suspicion that both of these points are inherently linked; companies are keen to ditch their principles at the first sign of trouble simply because they do not see value in them, and the reason they do not see value is because they fundamentally misunderstand the reason for doing it in the first place. Take TDD, for instance.  If you tell someone that they have to write tests for the sake of writing tests, and don't have a discussion or opinion about test-first or TDD as a design activity then they're probably not going to get any real value out of the activity. It will be seen as extra work with no pay off, and eventually people will start to avoid writing tests like the plague. The lip service approach just isn't enough to convince people to change their principles and values, at least not in the long term.

If you work for a company like this, it's important to realise that all is not lost. Someone above you in the organisational chart thought that the standards and principles were important enough to write up a PowerPoint presentation on, and maybe even paid for some basic training. They see a value in it (be it  a cultural alignment with their own beliefs, a financial benefit or something else), but for whatever reason they just don't properly understand what the end product should look like. If you see a topic that is near and dear to your heart being butchered by your employer, find the person who is doing the butchering and help them understand. Explain what the concept is really about, and what the real benefits are. Even if they just want to ride the buzz word wave all the way to the bank, they still want to see it succeed, leaving you with an opportunity to nudge the ship in the right direction.

Consulting Contracts for Developers 101

If you're a developer that works for a consulting firm, chances are you've never really thought about the contract that you're working under. Managers can take care of all that stuff while you look after important things like shipping features to users, right? Well, not exactly.

Before we get to that, let's define exactly who we're talking about. Generally, you're a consultant if:

• You work for a consulting firm (obviously)
• Something other than your time is being sold to a client

You're not a consultant if:

• You work directly for the client
• You're a contractor working for the client either directly through a specific contract or indirectly through a proxy such as a human resources company and the contract solely relates to the customer buying your time

Now that we've got that out of the way, what do I mean by "something other than your time is being sold to a client"? Well, consulting companies make their money by taking what you do and reselling it to a client with some sort of value-add on top. Different companies have different offerings and different "value-add" that they sell on top, and clients will pay a varying premium depending on the specific nature of these services. The important thing to note is that when a customer engages with one of these consulting companies, there is an expectation that they will get something a little more than 8 hours a day of a developer's time. After all, they are paying a premium.

These extras that the client is paying a premium for can take the form of something tangible, such as methodologies, templates or software assets, or something intangible like access to a staffed bench so that the client doesn't have to go to market to hire new developers. it can even include access to additional services like architectural reviews or research and development centres that can provide advice and knowledge on specific topics. In fact, it may even be something as simple as getting access to developers that have a guaranteed level of training and experience and are involved in a monitored continual improvement program. Whatever it is being offered, it's important to realise exactly which one of these extras the client is expecting from you.

Some of these extras may be implied and not contractually enforced; for example getting access to a consulting firm's bench is something that a client would just take for granted, and it makes it's money back through the fact that the developer is able to start sooner than going directly to the job market. Same goes for getting access to highly skilled staff. This premium would be earned through reputation and referenceability, and justified by continual high performance at a client site. It's still good to know what the client expects so that you can manage those expectations at a personal level. Hopefully no professional consultancy would sell you onto a client gig under false pretenses, but it's always good to know in advance that the client expects you to be an Oracle Forms 3.0 expert even through you were still in Grade 2 when the product was originally released. At least it would give you time to browse job sites for a job with a more ethical firm.

Where it gets interesting is when the extras are contractually enforced. When the consulting company and the client agree to work together, in most cases they'll come to some sort of agreement as to how that engagement will work. There are some tangible extras that can be thrown into these contracts, especially in the case of methodology and assets. As a developer on a project you want to make doubly sure that you're not, for example, using company IP to develop a solution for a customer when they don't have a licence for it, meaning rework and additional cost. The part of the contract that makes the most difference to a developer's life, however, is how the work itself is packaged.

Work can be packaged in a number of ways:

• Fixed Price
• Time and Materials

In both of these scenarios it is vitally important that the development team continue to feed back accurate information about estimates, risks, issues, potential functional gaps and anything that may affect cost. Regardless of how the customer wishes to pay, the customer is still paying and needs to know what they are getting. As a developer doing the work you should be taking responsibility for at the very least reporting back up the chain of command whenever something isn't going as expected.

One thing to note: I talk a lot about the behaviours that these contracts can drive. I don't necessarily mean that this is exactly how either party will behave if this contract is used; it's more that there's an advantage to one of the parties if that behaviour manifests itself. Most reputable clients and firms would hopefully not engage in such behaviour, although stranger things have been known to happen. It is important for developers to recognise the potential impact of these behaviours and watch for any signs that they may be occurring. Once a problem is recognised it can be dealt with, but the first step is admitting that there is a problem.

Fixed Price

Fixed Price engagements are exactly that; customers agree to pay the consulting firm a fixed fee for a specific service. The nature of this service depends on the contract. These deals usually have a contingency clause built in that allows the consulting firm to draw down on extra money if certain conditions are met. It is important for senior members of the development team to be aware of what these conditions are and know when to identify the need to use this extra money to their Project Manager.

The attraction of Fixed Price engagements for a consulting company is that they stand to make a lot of money if they deliver to the terms of the contract by spending less money than they originally thought. The risk is that if it costs the consulting company more money to deliver on the agreement then they stand to lose money on the deal. The attraction to the client is that there is a known amount of money that they will pay for the agreed service, with the risk being that they may pay more than is necessary for the agreed services.

Exactly what is being delivered for the fixed price varies, but can generally customers would be signing up for either agreed deliverables and functionality or a fixed amount of time (say 500 hours of a Senior Consultant's time). The former is usually referred to as "Fixed Scope" and the latter as "Variable Scope".

Fixed Scope projects are often associated with the words "change request". Anything that the customer wishes to do that was not agreed upon up front must by added to the scope by applying a change request on top of the original proposal. Developers need to be aware of this, especially if there were plans to run a project in a remotely agile manner as the constant administrative overhead of agreeing on change requests for every new feature can make it easier to opt for a more up-front development methodology. This may not necessarily be pure waterfall, but it may involve coming up with initial high level requirements for the entire system and including enough room in the estimates to be able to accommodate slight variations in requirements as part of an iterative development process. All architects, team leads and senior developers on the team should be across the change request process so they can identify functional variances early on.

Developers must also be keenly aware that they are contractually obligated to provide the required scope, regardless of whether the customer actually needs it. That means that if the customer no longer needs feature X which was included in the original scope then this should be identified and change requested out of scope. There's nothing worse than a customer refusing to pay because you failed to meet contractual terms even though you met their functional needs.

Senior delivery team members will also need to be cognizant of where the money for change requests is coming from; some projects may simply use the contingency money to pay for any change requests and have no ability to pay for extras once that money is gone, while others may be able to go back and request additional budget. This may not immediately seem like something the delivery team should be aware of, but being on the front line means that you are also the first ones to potentially make promises to the customer that cannot be met. Imagine telling a customer "don't worry, we can change request that feature in" when in reality the pot of gold set aside for change requests ran out in the last iteration. Not good.

Fixed Scope can lead to some strange behaviours in both client and consulting firm. If you think about it, the client has an incentive to get as much additional scope in under the radar, perhaps by classifying it as something that has already been agreed or by leaving a requirement sufficiently vague enough that they can push for additional features to meet it. It's in the consulting company's best interests to do the work as quickly and cheaply as possible, as the less it costs the more money they make. This could lead to corner cutting or arguments over scope that wouldn't happen if a contract with better incentives was used.

I've often found that customers who specifically ask for Fixed Price - Fixed Scope on their first engagement never end up asking for it again, as the change request process is so frustrating. Unfortunately the nature of this contractual mechanism means that customers can often end up with either an administrative headache or a system they don't want if the initial analysis isn't somewhere in the ballpark.

Variable Scope projects are significantly different, as effectively all  the customer is doing is pre-purchasing a block of time. There is no commitment from the consulting firm on the scope that will be delivered, but there is a commitment to provide a certain number of resources for a certain number of hours to do "stuff". Now, this might sound fantastic, but developers should realise that the customer still has expectations around what will be delivered, and there's still a fixed amount of cash available to do the work. Once that money is gone, if the project is not finished then you'll be in change request territory.

It's important to get a good idea of what the customer expects to be delivered for this money so that there are no surprises, and the team should obviously involve the customer in the development process so they are up to speed with how things are going. Saying that, the Variable Scope approach does allow for a more flexible requirements gathering process, and can support more agile methods if the customer is on board with the idea. The consulting firm can still get the "advantages" of Fixed Price by either delivering something the customer is happy with before the alloted time is up or using cheaper developers to do the work, and the client still knows that there's a maximum amount of money that they are going to shell out, even if they can't hold the consulting firm to any sort of agreed scope.

The behaviours driven by Variable Scope projects are not necessarily fantastic. It is in the customer's best interest to try and get the consulting firm to do as much work as possible during the allotted time. This can lead to massive scope creep and a generally unmanageable project, and funnily enough it can also lead to customers requesting that developers cut corners or quality in order to add additional functionality. This is especially true if the development team is obliged to fix any bugs introduced in agreed functionality; once you agree to built it in a shoddy fashion it doesn't mean that your agreed defect rate has suddenly changed. On the flip side, it is in the consulting firm's best interest to get the customer to agree that the project is finished as soon as possible, or to swap out all their key resources with cheaper ones.

Time and Materials

Time and Materials is the "pay as you go" approach to consulting. The client has a rate card or something similar detailing what each resource costs, and simply pays for the time that is used. These contracts generally come in two flavours: Uncapped and Capped.

Uncapped Time and Materials gigs are my favourite type of contract. Obviously there is the potential for the consulting firm to want to elongate the development process to milk more money out of the client, but this usually offset by the client now having some skin in the game from a financial perspective; if they can own the scope and take an active part in the delivery of the project then they will pay less. It's amazing how money can be a motivating factor, especially if the person who owns the budget is particularly close to the project. These projects are also generally the best vehicle through which to attempt a more agile project with less up front requirements gathering.  Once again, the customer must be on board with the process as it's their money that is being spent, but the freedom afforded by this type of contract means that developers can more easily adapt to implement features that are actually needed, and even abandon features that present no business value.

These Uncapped Time and Materials projects usually provide a great opportunity to make real improvements to a business, especially if the client is receptive to IT and change. You'll have a much better chance of getting someone to agree to ditching the 3 weeks worth of work you've already spent on Feature X to spend 6 weeks on an alternative solution that has greater business benefits if the change can happen at an iteration planning level rather than having to go all the way up through the PMO.

Capped Time and Materials contracts present no real "win" for a consulting firm. If they finish early then there is no bonus, and if they go over time then work simply stops and things often degenerate into a slanging match as there was no agreed scope that a customer can tie the development team to. Not exactly the healthiest way to end a project. Effectively a Capped Time and Materials gig is a Variable Scope Fixed Price engagement with no upside for the consulting firm.

With Capped Time and Materials, it's generally a good idea to do some sort of initial scoping as part of the project and start doing enough documentation to avoid any arguments about what is still left to implement when the money runs out. All members of the team need to be keenly aware of how they are tracking against estimates, and customer expectations need to be properly set at all times.

There are other contractual mechanisms through which a client can engage with a consulting firm, but those are some of the most common. There are also other common factors to be aware of such as support and warranty arrangements, roles and responsibilities, defect rates and agreed scope, but those are a story for another day. If you work for a consulting company this then I hope that you take an interest in exactly how your current and future engagements are structured so that you don't get caught out with some of the common pitfalls I've mentioned above.

Fast Food Development

The idea of trust within a software development team is an interesting one. Jeff Atwood argues that a lack of trust between management and the development team can lead to "micromanagement zombies" who mindlessly follow anything management tells them without contributing creatively. I believe that the issue is much more complex than this, as demonstrated by the following comment from the post:

OK, what do you do if:

• Your team regularly commits errors to make the editors of Daily WTF blush?
• They've been doing it that way their entire career and aren't very interested in changing?
• They're above average coders in the SE Asian nation you live in?

At least you can shoot zombies.

What we have here are two totally different approaches to software development: Fast Food and Gourmet.

The Fast Food approach delivers a bland product that is frequently prepared incorrectly, but it does it fast, cheap and using unskilled resources. The Gourmet approach delivers a higher quality product, but may take longer, will certainly cost more and requires a more experienced resource to prepare.

Successful fast food chains invest millions in making meal preparation as idiot proof as possible. Flashing lights and screeching sirens tell their employees are told when to wash their hands, when to flip the burgers and when to change the oil in the fries. They are micro-managed to the hilt simply because management do not trust their employees and expect them to fail if left to their own devices.

In contrast, a gourmet establishment has higher expectations of their staff. At the very least, they expect them to know how to cook as opposed to how to follow a checklist of specific orders. Most restaurants have to trust their staff to be able to perform their jobs to a certain level without specific instructions.

This parallel exists in many industries; for example, a master luthier would be trusted by his or her management more than the employee working the line in a factory that produced cheap, mass production guitars. Each has a place: some people want to spend $10,000 on a quality custom guitar, where as others would prefer to spend $150 on a cheap hunk of plywood that sort of looks like a guitar. To each their own.

The software development industry is no different. As much as some people would hate to admit it, there is a market for horribly written software that is impossible to maintain but was developed for minimum wage. It may be cheaper to produce a quality product using quality resources and best-of-breed practices, but that is irrelevant when the customer simply does not care about, or cannot afford, quality. These are the same customers who consider Access a viable solution, and who would have never been able to afford custom software before the advent of VB6.

To service these clients it may be necessary to use inexperienced or low-skilled workers and use management practices similar to those found in fast food restaurants. If you know that your resources are incapable of developing a product without guidance then all you can do is hope that they follow instructions and review, review, review.

I'm fortunate enough to work in an environment where high quality resources are the norm, but I have also consulted in the small business market and seen first hand just how common Fast Food Development is out there in the "real world". Regardless of developer idealism, cheap, dodgy software development is the oil that keeps the wheels of business running. As a quality developer you may not want to work in environments such as this, but that is no reason to stick your head in the sand and pretend that they do not exist or are not an important part of the software development landscape.

The Truth, The Whole Truth, and Nothing But The Truth

There's no denying that recruiters deliver a useful service to the IT consulting industry; without them we'd never be able to hire personnel with more than 2 or 3 degrees of separation from our current employees. However, the extended reach comes at a cost. The recruiters themselves are not IT consultants, and they also have limited time. This means that they need a way of placing candidates in positions that does not involve deep knowledge of the domain or a vast amount of time. A really effective way of doing this is through tagging.

The problem with tags, though, is that you can game the results if you know what people are searching for. The IT job market realised long ago that common industry buzz words and "hot technologies" form a large portion of the obvious tags that recruiters will be searching for. Since then candidates have been peppering their resumes with them in order to catch the eye of recruiters.

The good news is that job seekers usually won't put in keywords that have nothing to do with their technology space, meaning that you still get .Net developers sent through for .Net jobs and Java developers interviewing for Java jobs. The bad news is that a lot of candidates are rather liberal in lacing their resumes with terms that they think the employer will be looking for rather than terms that actually reflect their experience and understanding. They also have a tendency to apply this focus on keywords to the other parts of the interview process. What they don't realise is that no one involved in the actual hiring process cares about buzz words, so they are going to assume that you have experience with whatever you mention and treat you as such.

This is especially true at technical interviews. If you've indicated that you know all about XP, TDD, DDD, ORM and a bunch of other cool acronyms then you should expect to be asked questions about them. Questions like this usually carry much more weight, as you have set an expectation. To falter here indicates that you have either been dishonest or just don’t know what you’re talking about.

For example, if the interviewer asks you about a technology you know nothing about and you haven’t given them any reason to think that you know something about it then it's perfectly acceptable to say “I don’t know”. If, however, you indicated that you knew of the technology in question then not giving a decent answer looks really bad.

It's not uncommon for a potential employee to mention a technology that they know nothing about just because they might think that the interviewer wants to hear them say it. Pro tip: If a company wants you to mention random technologies you know nothing about just so they can tick it off on a list then that's probably not a company any decent consultant would want to work for. Any company worth their salt should be looking to assess your current abilities and your potential to grow, not trying to check off a list of buzz words to see if you are “compliant” with their “technology stack”.

So please, next time you submit a resume or go for an interview just try and focus on your actual experience and aspirations rather than getting hung up on what you think the company expects you to mention. Remember that there’s a good chance the person interviewing you either does a similar job to the one you’re applying for or has done in the past, so they’re going to be able to call you out if you don’t know what you’re talking about.

The Drudgery Report

I was recently interviewed by Sheila from Sheila's Wanderings. Typically for me, I ended up with a longer answer to the "Any last words?" section than any of the others. The tone of the questions really got me thinking about my first year of University, when I was amongst 200 other students looking forward to a prosperous career in a DotCom bubble.

To quote myself:

I can remember starting my degree with around 200 people in my course. By the end of the first year, over half of them had figured out that IT wasn't all about playing computer games. I'd say that around 30 students out of that initial 200 actually made it through the degree still wanting to get a job related to the field. Make sure it's something that excites you, and if you HAVE spent three years on a computer science degree and don't want to use it just remember that you can always take a post-grad degree in something totally different. You have to live and breathe IT or the grind of continuous learning will suck the life out of you. Well, either that or you'll stop learning and will soon find yourself relegated to the sidelines.

It was 1998, and the media were all over IT. The buzz surrounding anything even remotely related to computers was so prevalent that every man and his dog wanted in on the action.

Over the course of that first year I saw a large number of my classmates gradually come to realise that Computer Science was nothing like the media spin. Many of those disaffected with the degree dropped out at the end of the first year, but quite a few stuck around till the end of the degree, with some even ending up in industry jobs. The disaffected students became disaffected employees.

I'm incredibly lucky to get paid to spend 8 hours a day indulging in one of my favourite hobbies, so I guess I've always felt sorry for those who were inclined to settle for something less than that. I can't relate to other fields, but I can say for certain that a career in IT isn't for everybody, and that's nothing to be ashamed of. It's a discipline where happiness is usually accompanied by a constant desire for self improvement, and any hint of stagnation breeds disenchantment. If you have no personal desire to better yourself then you are probably in the wrong field.

The most important thing to remember is that even if you have spent several years training for a job that you have no interest in, it's not the end of the world. It's never too late to discover how to get paid for something you love to do, and there are plenty of options for re-skilling.

If you already have a Bachelor's Degree then Post Graduate Diplomas and Degrees are always a good bet, as is simple on the job training. Many degree-based jobs simply require that you have "a degree", as well as some enthusiasm for the role. You might not be starting out as the CEO, but at least you'd be on your way to enjoying your work.

If you do have a degree that you're unhappy with and want to move into a role that does not require a University education then you may end up viewing your time at Uni as wasted effort, however all is not lost. The primary goal of University is to teach you how to learn, which is always a useful skill no matter what you end up doing. If you find that a 12 month TAFE course will lead you to career fulfillment then don't let your previous efforts influence that decision. There's no point in being compelled to continue down a path of drudgery simply because you've spend 3 years walking down it. The principle of not throwing good money after bad applies to your career too.

If you're not happy with your job, regardless of the industry you are currently in, just ask yourself "what would I rather be doing?". If the answer is "not this" then you may want to give some thought to what would make you happy, and what it would take to get you there. Many of us would have been in the workforce for a long, long time before we can officially retire, so spending a few years here or there to figure out how you can be happy for the majority of your waking hours isn't really a big ask.

Walking the Line

Consultancy is a hard gig. Most companies walk a very fine line between body shopping and offering professional services.

An organisation favouring body shopping usually hires consultants for a particular contract; with no long term view on how that employee could be best utilised to grow the company. The organisation often charges clients per hour, and usually has little to no control over the running of the projects that their staff members are working on.

The employee is often placed out a client site with little or no exposure to the goings on in the larger organisation. Eventually boredom sets in or the contract runs out, and the employees move on to the next body shopping firm in a hope that the grass will be greener on the other side.

Organisations offering professional services tend to be more interested in providing highly skilled resources to perform a particular task. The entire project or service is usually managed by the consulting firm, and employees are often seen as important resources that can benefit the company in the future.

In reality most consulting firms tend to flip-flop between the two. Some companies favour one style over the other, but most of the time you can find elements of both in an organisation.

If you think being a consultant is a lonely an unfulfilling job then congratulations, you probably work in a body shop. The lack of employee focus encouraged by this approach leaves many guys in the business asking why they bother getting out of bed in the morning. The good news is that it's not body shopping per se that is causing this dissatisfaction; it's the approach to staff development and corporate culture that normally goes along with body shopping.

Succession planning is often spoken about in terms of how to better position a company to replace key resources in the event of unexpected staff turnover. What many people don't realise is that the core principles of succession planning (mentoring, training and job rotation) can often help fight the feeling of stagnation that goes along with working in a consulting firm, in turn helping to increase retention rates.

Any developer worth his salt is looking to improve his skills, and training and mentoring are two great ways of helping a developer do just that.

A formal training program with links to industry based certification always helps, but it's also expensive to implement. Maintaining a library of recommended reading and encouraging staff to read them can often be enough to show that the developer's personal growth and career development is important to the company. Staff training has the nice side effect of giving the consulting firm access to an increased skill set that can be on sold to clients.

Another way to create a positive learning environment for is to get developers talking amongst themselves. This could be through one on one mentoring, a group based discussion forum or some other means. It is often good to encourage this amongst groups who would not normally mix, e.g. two different project teams working with different clients. This is even more important for the employees out on client sites, as it lets them know that they are part of a larger company and gives them something to belong to. It gives the impression that they are part of a larger practice that has goals outside of their current engagement.

It's my belief that job rotation is the most important practice that a consulting firm can take from the book of succession planning. Sure, it mitigates risk by ensuring that more than one person knows how to do a particular job, but it also helps to fight boredom, and, above all else, it increases the exposure a developer gets to other areas of the company. This exposure is vital to negating the "cubical drone" effect usually brought on by long term client engagements.

Keeping everyone fully billable reduces organisational agility, and even encourages body shopping. If there is no one available to take on new work then the temptation exists to hire in resources just to cover specific projects. Maintaining a strong, healthy bench reducing expected chargeability rates can help enable all the benefits of succession planning. Staff working back at base camp could be busy training, mentoring or helping with pre-sales work, all while being available to take on new work should it arise. This can help to maintain a happy workforce who actually want to come into work every day, which can only be good for the company.