In a recent post I spoke at a high level (and at length, it seems) about the things developers need to know about different consulting company contracts they might encounter in the workplace. After reading the article, fellow Perthie and all round awesome guy Mike Minutillo pointed out that there's some good information in that there about what different contracts cause people to do, but it's hidden in a big sea of text.
To that end, here's a list of the key things that each contract incentivizes the different parties to do. If you want a more in depth explanation of each contract type then check out the aforementioned post. It should be noted that these are not things that you're guaranteed to get; it's just that typically these contracts encourage people to act in a certain way in an attempt to "win the contract". It's by no means complete, but it should be a good start.
|
Consulting firm is more likely to... |
Client is more likely to... |
| Fixed Price - Fixed Scope |
- Scrutinise all work for potential scope creep
- Work as quickly and cheaply as possible
- Ignore long term maintainability in favour of short term implementation, resulting in reduced quality
- Swap in cheaper resources to reduce the budget burn rate
- Make heavy use of the change request process to capture even the slightest variation to the contract
- Aim to finish well under budget, as they get the same amount of money regardless
- Require that clients define requirements up front
|
- Create vague requirement documents that are open to interpretation
- Approach individual developers in an attempt to convince them to implement scope "under the radar"
- Argue that features are in scope by expanding the meaning of agreed requirements
- Try to avoid drawing down on agreed contingency as it is the only variable funding in the project
- Rush the requirements gathering process in order to have enough information to sign a contract
|
| Fixed Price - Variable Scope |
- Swap in cheaper resources to reduce the budget burn rate
- Give extremely conservative estimates to the client to reduce pressure on the development team
- Argue that features are not required
- Push for project completion as soon as possible. They still get paid for all the hours even if the hours are not needed.
- For for re-estimation, change requests and draw down on contingency for any scope change
|
- Demand a deep level of analysis up front in order to determine the budget
- Demand estimates at an early stage of the project to determine timeframe and appropriate burn rate
- Stick to early estimates as the project progresses, even if requirements have shifted
- Watch development team closely to ensure that value for money is being had
- Be even more reluctant to draw down on any contingency
- Try to get the consulting firm to do as much work as possible during the time period
- Argue with the consulting firm over estimates
- Blow scope out of the water simply to get "better value for money", potentially leading to waste and unneeded features
- Request that developers cut corners and reduce quality to fit more functionality in, especially if there is a warranty clause in the contract that will force the consulting company to fix any defects for no cost at a later date
|
| Time and Materials - Capped |
- Swap in cheaper resources to reduce the budget burn rate
- Push to make the work track closely to the estimates, often at the expense of functionality or quality
- Restrict client's access to developers in an attempt to limit scope creep
|
- Demand a deep level of analysis up front in order to determine the budget
- Demand estimates at an early stage of the project to determine timeframe and appropriate burn rate
- Stick to early estimates as the project progresses, even if requirements have shifted.
- Watch development team closely to ensure that value for money is being had
- Argue among themselves over what scope to implement during the project, given that there is a cap on the amount of time that can be engaged.
- Try to get developers to make promises around feature delivery that can then be used as ammunition if the project does not go to plan
|
| Time and Materials - Uncapped |
- Attempt an agile delivery
- Attempt to artificially elongate the project, usually by making claims around quality, process or procedure
- Use the most expensive resources available to perform the work
- Be able to actually develop with an appropriate level of quality
|
- Watch development team closely to ensure that value for money is being had
- Feel comfortable defining detailed requirements as the project progresses
- Change their minds on scope, potentially producing waste but usually resulting in a better outcome
- Get the software that they want/need
|
I've always wanted a cool syntax highlighter for source code on my blog, so when performing the latest revamp of my blog I decided to go hunting for a solution that would fit my needs.
Part of the ethos of my latest blog revamp is that I don't want to be editing configuration files, modifying templates or adding anything that can't be configured using the standard WordPress admin tools. For the last few years I've been unable to easily upgrade my template to make use of new WordPress features simply because I had implemented a lot of functionality by hacking at the various files within the template. This meant that although there are a number of JavaScript-only based solutions, I would need something that is packaged as a WordPress plugin to save me having to modify my template files.
A quick scan of the WordPress plugin gallery revealed SyntaxHighlighter MT to be a reasonable sounding option. It's based on Alex Gorbatchev's excellent SyntaxHighlighter, one of the afformentioned JavaScript-based solutions for formatting source code, and was based on the use of <pre> tags meaning I wouldn't have to worry about inserting HTML special entities all over my code whenever I needed to post something.
After installing and converting over several posts I started to notice two main issues that were effectively show stoppers:
- Anything that looked like an XML tag was being made lowercase
- Anything that looked like a start tag of an XML element that didn't have a corresponding end tag was having one automatically inserted
This may not sound like a huge deal, but the second point was especially painful when using non-XML-based languages. Take generics in C#, for instance. If I wanted to write a line of code like this:
IList<Customer> listOfActiveCustomers = customerService.GetActiveCustomers();
SyntaxHighlighter MT would spit out the following:
IList<customer> listOfActiveCustomers = customerService.GetActiveCustomers();
</customer>
Not only did it mess up the casing on the Customer type, it thought that the generic type parameter to IList was the start of an XML tag and thus needed to be closed.
Now, I'm guessing this has something to do with how WordPress in general processes text inside a <pre> tag and is probably not the fault of the plugin author, but that still didn't change the fact that I needed a solution.
The WordPress.com guide to posting source code noted that WordPress.com blogs have access to the "sourcecode" WordPress shortcode to accomplish the very same thing. Now I'm not using WordPress.com, I self-host my blog using the WordPress.org code, but they do mention at the bottom of the post also indicates that the same functionality is available through the SyntaxHighlighter Evolved plugin.
This plugin also uses Alex Gorbatchev's SyntaxHighlighter, but it uses WordPress shortcodes just like the functionality available through WordPress.com. I've now installed the new plugin and started converting old posts over to the new format with no issues whatsoever.
