Mar 29, 2008

Syntax Highlighting for Powershell in Notepad++

If you ever find yourself doing any Powershell work (maybe when using TFSDeployer for example) then you'll probably be editing .ps1 files in a text editor (I hope you're not still using notepad!!).  My personal tool of choice is Notepad++.

Unfortunately most notepad replacements still aren't aware of the syntax rules for .ps1 files and treat them like plain text.  But fret no more - you can now get powershell syntax highlighting in Notepad++.  Have a look at and download the language definition.  It works a treat!

Here’s what it looks like in action:


Nice! Thanks Jon!

As a footnote Steven Nagy had the following to say in a recent conversation we had:

I had a nice play with PowerGui today and think I will keep both handy. PowerGui gives you intellisense and richer syntax highlighting than Notepad++

However you can open 5 ps1 files in NP++ in one click and they all open in ONE window, unlike PowerGui which creates a new instance with each file. Other than that, PowerGui owns. And it costs the same: $0.00

Mar 26, 2008

A Tale of Two Companies

There were once 2 companies who both wanted to develop some custom software to help their businesses enter an evolving market and gain a competitive edge.  Both companies made an initial approximation of the costs involved in getting the software developed and both companies set aside a similar sum of money for the project.  Neither company had any real appetite or skill for developing the software internally and decided to get external companies to help.

Company A

Company A decided to take the traditional, recommended, "best practice" approach for getting the software developed.  It's what they'd always done in the past, it's what their project managers recommended and even though they'd never had a project come in on time before they hoped that if they  did things right this time then it would all be OK.  They also decided to set aside a portion of their budget just in case there was some overrun in the project.

Because Company A wanted to get the best value for their money they decided to put out a tender.  They knew that a tender would give them a result they wanted for the lowest fixed price and they'd get everything they asked for.

They also wanted to get the tender right. They knew how many software projects failed but they figures that that was mainly because requirements in tenders had never been quite right before. If they could get their tender requirements right this time then it would give them their best shot at a successful project and they'd be able to enter this new market with confidence.

Company A decided that the best way to get requirements right was to get in an external expert to help draft and clarify the requirements and to word the tender in the best way possible so that anyone could to clearly understand what it is that they were after.

It takes a week to find the right expert and during the initial meeting the expert listens to the high level overview of the project and estimates about 6 weeks to get the tender ready.  The expert then starts talking to the stakeholders in the company and begins to draw up an initial draft of the tender.

The expert uncovered more requirements than were initially explained and, as this was a perfect opportunity, a number of stakeholders added wish list items to the tender to be included as low priority items. After two months the tender draft is ready and placed before the stakeholders for review.  Everyone in the company understood why the extra 2 weeks were needed to get the draft completed and thought that it was time well spent, especially as some critical requirements were discovered that would otherwise have been missed.  Unfortunately the review also determined that some of the requirements weren't well described and others some seemed to have been misunderstood.

2 weeks later the revised draft was again presented to the stakeholders for review.  There were still a few things that weren't quite right and a couple of the stakeholders were unable to attend due to scheduling conflicts but as the tender had now taken a month longer than estimated the remaining stakeholders signed off on it and got the project moving.

The published tender had over 400 requirements and suppliers were given a 4 week window in which to respond.  Responses when they arrived were larger in both number and size than expected and the review of the responses took 4 weeks to score and complete before a group of 3 potential suppliers were short listed and allocated a day each to present their proposals, 2 weeks after being notified.

Now after 20 weeks the company was at the point where they were ready for vendor presentations.   And they still had no software to show for it. Plus they'd spent 15% of their project budget already.


Company B

Company B took a rather different approach.  They'd been burned by tenders and fixed price, fixed scope contracts before and their CIO had read about agile development and some of the success stories that were talked about.

While it was considered a risky approach,  the CIO knew that repeating what had failed before in the hope that the result would be different was the very definition of insanity, and recommended that an agile approach be taken and immediately set about locating a number of potential vendors who could deliver a project using an agile methodology.  After 2 weeks the potential vendors had been contacted and a preferred vendor chosen.  The CIO and the vendor also took an unusual approach to the contract. They agreed that cost would be limited, but that scope would not.  A minimum set of functionality would be delivered but beyond that anything could be changed by the company.  Company B could terminate the contract at any time of their choosing, as long as they paid out a portion of the remaining contract.  The vendor would deliver the highest value software they could using a prioritised list of requirements as determined by Company B. The vendor also stipulated that they wanted to have a single representative of Company B to work with, not a committee. Changes to functionality, priorities and requirements were allowed at any time with no extra cost so long as those things changed were not currently being worked on.  If Company B wanted to add new features or change existing ones then that was their right.  The vendor also agreed to deliver regular releases of the product so that the company could see what was being built and could optionally put that code into production should they deem it appropriate.

It took a few more weeks to get the legals and the resourcing of people sorted out but even so, the project kicked off 4 weeks after the initial "go" decision.

During the initial week of the project stakeholders from Company B and members of the vendor's project team sat together and worked out a prioritised list of high level requirements.  Many of the requirements were still somewhat vague but the vendor wasn't concerned - they would work with Company B's people to clarify those requirements better once they got to them.  Each requirement was given a relative effort estimate based on how much effort there might be compared to other requirements in the list, and was also given a simple set of criteria to help determine when a requirement could be considered complete.  After some consultation with the vendor the prioritised list of requirements was altered slightly to take into consideration any cross-requirement dependencies and pre-requisites but the end result was an order list of things that Company B wanted in their software.

The very next week development work began.

The vendors team started by taking the 4 first items from the requirement list making a commitment to complete them over the next 3 weeks, saying they would have something finished that they could show the people of Company B when the time was up.  However the CIO was a little concerned - 4 items didn't seem like that much to work on.  However after the team talked through how much code and database set up needed to be done in order to complete a single item the CIO was willing to go with it.  At worst they would waste 3 weeks and if they didn't like what they saw they could always terminate the contract.

Over the next 3 weeks the team set to work.  However the teams definition of work was a little unusual, they didn't go and lock themselves away and then turn up 3 weeks later with something to show, they were very visible, spent a lot of time asking people questions, clarifying what they were doing and getting stakeholders together to make sure they understood what needed to be done.Plus there were all these wall charts and sticky notes being stuck up on windows and walls so that anyone could see what was being done by the team and how they were tracking.  For the first time people in Company B could see what those mysterious developers were actually doing.

At the end of the third week of development the team got the stakeholders together and showed them what they had done.  All 4 items they took on were there and working.  No smoke, no mirrors. Plus the people from company B were allowed to play with that version of the software whenever they wanted.  Company B was quietly pleased.

The next week the vendors team took on 12 items to deliver in 3 weeks.  Now the CIO was thinking that they'd taken on too much.  But the same thing happened - lots of communication, lots of conversations and at the end of the next 3 weeks more product was delivered and things were coming together.  Company B was starting to take notice.

Shortly after this some of the Company B people were playing with the software and realised that with what they had already it would be a great idea and would really improve things if they could make a few changes to what they had planned.  They hadn't thought of them before, but now that they had seen the software and how it was shaping up it just seemed so logical.  The vendor was quite happy for the company to add requirements to their list, just as long as the list was re-prioritised and anything they didn't want any more was removed.

This pattern of work for another 4 iterations and at the end of the fourth iteration the CIO and the stakeholders looked at the product and realised that all of their main functionality was already in place.  There were still a lot of items on the requirements list, but they were low priority items and probably not worth the development cost, at least not for an initial release.

After 23 weeks the software was put into production.

As everything that was needed was already delivered Company B decided to terminate the contract and saved around 40% of their budget.  The money saved then went into further efforts to open up a lead in the emerging market giving the company even more of a competitive edge. As for the vendor they became the sole supplier of development services to Company B from that point on.


Company B was already up and running with their system and starting to make inroads into the new market before Company A even got the development work started on their project.  Over the next few years Company B continued to push hard providing their customers with regular updates to their offerings, adapting to the changing state of the market and managed to do so at a pace that no-one else could get close to matching.  When Company A finally made their venture into that market it was with a poorly conceived, me-too product that cost way more than budgeted and didn't work anywhere near as well as that of the established players.  Company A withdrew from that market not long after.


Before you ask - no, this isn't a story based on any specific companies.  But it is a story I'm sure you can relate to as this sort of thing happens all over the world every single day.  There are still far too many Company A's in this world and we should do all we can to help turn them into Company B's.

I'd love to hear your comments!

Mar 12, 2008

Firefox 3 Beta 4 - A Mini Review

With IE8 Beta 1 finally getting out the door at Mix08 last week I figured I’d check on the competition and spark up FF3 Beta 4.

Here’s a quick summary of what’s new (from a visible perspective)

1. Speed – it’s sooo much quicker to use.  You’ll notice the difference in ajax heavy apps (google reader, etc) as well as in general rendering.

2. Downloads now get virus checked.  Nice.

3. New address bar – very funky.  Not only address search, but titles as well

4. Most FF2 add-ons don’t work.  You’ll need to find updates.  Here’s Firebug 1.1 beta (FireFtp has a beta you can get as well)
You can see the parallel loading has increased to 6-7 items instead of 2, which explains some of the speed boost.

5. Bookmarking is a little different – note the tagging.  Very cool.

6. IE8 Activities work and are available from
Adding activities from the IE8 activity gallery works, but Mitch’s Wikipedia activity doesn’t due to the use of IE8 specific javascript.  Even so...
results in

7. IE8 style Webslices can be got from but they’re still halfbaked (it’s obviously a quick hack and more work is needed)

When you try to mouse over the icon so you can add it, it disappears because you've left the webslice (doh!).  I’m sure there’ll be an update soon enough, but in the meantime you can right-click to add a “webchunk” which then looks like this:


Oh- before you make any comments on the content this is all legit ebay search results and all stemmed from the selection on the SMH web site.

8. Oh - it does occasionally crash L  But at  least the crash reporting is OK, and when you restart you can try and restore your sessions which is OK (unless the offending page always causes the crash).

Overall– a really good experience, but being beta I’d expect that there are still issues with it I haven’t seen in the short time I’ve used it.  Is it better than IE8?  Some people think so -

Mar 11, 2008

Improve Your Technical Presentations

I was watching Scott Hansleman’s ASP.NET MVC presentation this morning and noticed him zooming in on various screen areas and drawing around parts of the screen he was talking about during the demo.  “What the hell is he using to do that?” thought I.

Initially I thought it must’ve been a tablet thingy and that if I mentioned it Mitch would get all “nah-ne-nah-ne-nah-nah” on me.  But I did a quick bit of digging and learned that it’s actually a utility from the SysInternals team called ZoomIt -

I’ve downloaded it and played about with it and think it’s fantastic – it makes showing small fonts and display areas (such as the solution panel in Visual Studio) so much easier and avoids the usual presenters question of "Can you guys up the back see that?". I wish I’d known about this in the past. If you haven’t already seen it, I’d recommend getting it and trying it out.

P.S. Don’t worry about the size – it’s all of 74KB to download.

Mar 10, 2008

Castle Windsor

Spent a couple of hours this afternoon getting to know the Castle Windsor IoC container again.

I ran through the sample as a refresher and then converted a small app I had lying around to use loosely coupled services/components.

Talk about simple, easy and powerful.  I've read enough about this thing to know how it works and played with it briefly in the past, but the latest release adds support for generics and makes it so much easier to use than before (not that it was hard). 

The effort involved in converting an existing "hard wired" app to be one using loosely coupled services connected at runtime via the plumbing magic of an IoC container is obviously dependent on the current state of the app, but even so switching my app across was only a matter of adding a few lines of code and doing a bit of refactoring.

For instance let's say I have an app that parses some input, I could instantiate parsing and messaging services like this:

IWindsorContainer container = new WindsorContainer();
container.AddComponent<IMessageDisplay, ConsoleMessageDisplay>("console.display");
container.AddComponent<IInputParser, InputParser>("inputparser");

If I wanted my parser to display messages to the user when there was a problem I'd normally have to wire up the connection between the classes myself, but now I don't need to.  All I need to do is have a constructor for the parser like so:

private IMessageDisplay display;
public InputParser(IMessageDisplay display)
this.display = display;

and the Windsor container takes care of injecting the appropriate IMessageDisplay class for me.

The container looks after the lifestyle (singleton, pooling, instance-per-request, etc) of each service as well and the lifecycle (instantiation and disposal) of each object.

All that nasty plumbing that we typically have to do is removed and our application becomes so much easier to maintain.

Why do we still insist on writing code in such a tightly coupled manner?

A Commitment is not a Guarantee

When using Scrum for the development process a team begins an iteration by sitting with the Product Owner and working through which items from the product backlog they can complete by the end of the iteration.  The team then makes a commitment to deliver on those items and gets to work.

What sometimes happens is that a Product Owner will assume that the commitment by the team is a guarantee that everything will be delivered.  Even if they know better, when a team has delivered a number of successful iterations in a row it's very easy for a Product Owner to lapse into this thinking.

The commitment by the team is a statement that they are devoting themselves to getting all of the items in the sprint backlog "done".  But it is not a guarantee - a guarantee is a statement along the lines of "if we don't do this then we will ..." with some sort of remediation or punishment clause at the end.  So if a team guaranteed delivery then they would also be saying that there are potential remedies for not delivering, but what could those be? Docking of pay and/or working overtime? There's not much else is there? And the thing is, by the time an iteration concludes there isn't any more time left - overtime just eats into the next iteration and overtime itself doesn't resolve every problem, almost always creates new ones and gives birth to a tired team that makes more mistakes and takes longer to get things done.

So what does a Scrum Master do when a team has been unable to deliver on all their items?

First - do a retrospective and see what lessons can be learned.  Did the team work cohesively? Were there external dependencies that impeded the team? Did anyone on the team slack off?  Were there things forgotten during estimation? Unseen gotcha's? Ask the team - learn what you can, and take those lessons into the next iteration.

Second - talk to the Product Owner and adjust expectations for following iterations.  Explain to the Product Owner what went wrong, and what changes the team are making to address them and then reduce the teams velocity.

Note: punishing a team for missing a delivery is generally counter-productive.  They'll already feel bad enough for missing the target so don't pour more salt on the wound as it can be a demotivator.  Talk to the team, keep encouraging them, find out what happened and see if you can help them make the changes they want to.  Help them learn their lessons, communicate with the Product Owner and stakeholders about expectations and move on with delivering on the next iteration.

Mar 7, 2008

Finally - I'm Certified

I'm pleased to say that I've just completed my Certified Scrum Master course.  After 3 years of doing agile/scrum work I've finally decided to get some certifications.  The course was presented by Jens Ostergaard and he did a great job teaching people about the principles and practices of Scrum.  Also, rather graciously, he invited me to speak for 15 minutes and talk to the group about some of my experiences implementing Scrum in Australian companies.  I take my hat off to him for giving me the opportunity, and a chance to cheekily plug my blog :-)

For those who attended, I had a great time talking with you all, and here are some links you may find useful

The Australian Scrum Community

The SyXPAC Mailing List & Main Site (Wiki)

Scrum Development Mailing List (busy)

Control Chaos - Scrum Information by Ken Schwaber

Mike Cohn - Mountain Goat Software

Planning Poker

The Scrum Primer

The Agile Alliance