James Simmonds' Blog

Blog is moving...me too!

james.simmonds — Thu, 09 Jun 2005 14:36:00 GMT

Hello reader... The time has come to move on from Conchango . I've had a wonderful time here, nearly 5 years and it's been a real blast. I've learnt so much about top flight consultancy and most of this has come from the superb people I work with. If...(read more)

OpenNetCF Application Blocks arrive!

james.simmonds — Fri, 13 May 2005 07:17:00 GMT

Finally!

"The OpenNETCF team has worked with the Patterns & Practices team at Microsoft to provide a version of the Application Blocks for the .NET Compact Framework. Application Blocks are code used to address the common challenges that developers face from one project to the next that can be plugged into .NET applications quickly and easily."

Grab them here while they are hot! OpenNetCF, MS P&P team...guys, I salute you! :)

For the story behind the evolution of the AppBlocks - check out these links...

http://blog.opennetcf.org/ncowburn/TheApplicationBlocksStory.aspx

http://blogs.msdn.com/sandyk/archive/2005/05/12/416952.aspx

dotMSN - version 2.0 released

james.simmonds — Sat, 30 Apr 2005 18:10:00 GMT

Just received an email from Bas Geertsema, the creator of the fantastic 'dotMSN' .NET wrapper to the MSN instant messenger protocol. I used this component in my SendMSN utility and think it's ace - if you want to integrate MSN IM functionality into your .NET applications then this is THE library you need. The main highlights of this release are...

Full source code for the wrapper is now available!!
Backwards compatibility has been broken with v1.2 - however the new improvements make it worthwhile upgrading - just don't drop it into your project as a replacement for the previous version and expect it to behave the same
Implements MSNP9
Supports P2P file transfers

Check out the full story here

Encrypt your MSN IM conversations

james.simmonds — Mon, 25 Apr 2005 13:15:00 GMT

Encrypt your MSN Messenger conversations with this utility tip from Scott Hanselman. (Scott did such a nice job with the disclaimer bit I thought I would link direct to his post than create my own! ;)

Cool util for all those paranoid types out there...personally I'm not worried about when people know I'm heading off for lunch, how my weekend went or have I seen the new receptionist, but hey - each to their own! :)

Thought for the day

james.simmonds — Mon, 25 Apr 2005 09:00:00 GMT

Something struck me this morning listening to the sports report on the radio - Martin O'Neil said "[As the manager] you can talk until you are blue in the face, it's what they do on the pitch that counts..."

How about using Scrum to manage a football team?...Get rid of the manager, let the team organise and motivate themselves, would it work?

Team orientated
Clearly defined objectives
Agility to respond to different opposing team tactics, strengths & weaknesses
Inspect & Adapt - "how could we improve our performance from the last one?"

...discuss

Windows Mobile Smartphone PC dashboard

james.simmonds — Mon, 21 Feb 2005 15:38:00 GMT

In a similar style as the awesome FMA for the Sony Ericsson T610 series is this PC dashboard for Windows Smartphone (via Nino.Mobile).

"Smartione is a very nice little application that allows you to tweak and configure your Smartphone from your PC. Smartione allows you to view system information, transfer images and video, convert RSS feeds to HTML, edit your phones registry, explore databases, tweak various aspects of the interface, and organize your start menu, all from your PC"...

Hot diggety dog...what a great application! I love the FMA hook into Bluetooth so you can automatically lock your PC when your phone moves outside BT range - would be great if this supported something like this too....the next version maybe?!

Update 19.05.05: Version 1.4.1.0 Smartione has just been released, more details here (you might need to register to get the download link)

Updates include various bugfixes, a sound theme manager and an improved database viewer

.NET Compact Framework and Application Blocks

james.simmonds — Sun, 06 Feb 2005 10:20:00 GMT

Via Larkware (a little late I know but I'm really busy on a project at the moment)

Data Access Application Block for .NET CF

Hurrah! the first time I've seen these two things mentioned together and I'm excited!

Compact Framework
Application Block

Now I know the awesome OpenNetCF SDF is pretty much the uber application block for CF development but it feels like quite a monolithic entity - a better delivery of it would have been offering a more granular level of packaging and under the branding banner of "Application Blocks" (IMHO).

What's exciting about Application Blocks appearing on the CF is the feeling of consistency from the desktop platform which I feel is lacking. Obviously device limitations aside there will always be differences between the full and compact framework but building applications for a Windows Mobile device should be just as focused on the business portion of the application and not the plumbing stuff (and this is a double edged sword because one of the reasons I love CF programming is that there is still uncharted territory out there for you to write your own app block/utility methods).

Anyway, top marks to BusinessAnyplace and a gold star for using the moniker "Application Block" - nice work guys!

Update: Compact Framework Instrumenatation Application Block - check it out!

Overview

The "Compact Framework Instrumentation Library" (CFIL) is a combination of the following from Microsoft Patterns & Practices:

Logging Application Block (LAB)
Microsoft Instrumentation Framework (MIF)
Exception Management Application Block (EMAB)

Because we are on a constrained device we will have cut back on a lot of the functionality from the above three items and combine them into one. Also, there are a few differences from the original Application Blocks.

Desktop client to view the data on the device.
Since the .Net Compact Framework is a subset of the full Framework, we will use OpenNETCF.org Smart Device Framework (SDF) to supplement missing functionality from the Compact Framework.
Limitations in the Compact Framework (for example StackTrace) cause us to hardcode some values, such as the method name. With Version 2 of the Compact Framework this will no longer be necessary.

http://msdn.microsoft.com/smartclient/default.aspx?pull=/library/en-us/dnnetcomp/html/instnetcfapp.asp

Occam's Razor - Part I

james.simmonds — Mon, 20 Dec 2004 20:27:00 GMT

Well I've started my Christmas holiday today, the first period in over four years I haven't had to work up until Christmas eve (it's ok no heart rending stories of tenacity to get a project done type thing, I've usually used all my holiday allowance is all!) - 16 days of no work....bliss!

However I don't consider blogging work (perversely!?), even though I might be posting about work related stuff - I do find it theraputic on some level and I find it good to actually publish my thinking as it concentrates and clarifies my ideas (if you can't describe what you mean exactly then you will find you often get flamed to a crisp, trust me I've been burnt!).

So the trigger to this post is the book "The curious incident of the dog in the night-time", a good book so far I feel and one that I've been meaning to read for some time (purely so the owner Pippa can have it back). In it the main character mentions "Occam's Razor" - one of those phrases you dread hearing dropped into a conversation - a sort of anti-"selection of the thickest" phrase that whittles away to the bar or the other corner of the room those not "in the know" of its meaning...me included - so I looked it up and decided that it had relevance to software development.

"one should not increase, beyond what is necessary, the number of entities required to explain anything" - William of Occam

or my version for the software development world,

"one should not code, beyond what is necessary, the number of classes required to implement something".

This is not a new principle - Don't Repeat Yourself (DRY) and Keep it Simple, Stupid (KISS) have been around for a long while but it's a trap that is so easy to fall into - over engineering a solution.

It's quite problematic when working on an Agile project, as you just don't get bonus points for coding a feature that's not on the Sprint backlog. However good software design and clear instructions on why you haven't implemented it or how you could implement it are useful - so Part II of this post will be about what I feel makes a great developer, good commenting and leaness of code certainly being traits that are common - I'll be using examples from people I've worked with and maybe one or two from my own hand. I'll also be talking about how "Software Factories" will influence development practices in the future, I'm fascinated by the concept but would like to map out the reality of what this approach acutally means to software developers.

Have a great Christmas!

MSN Toolbar/Desktop Search Engine

james.simmonds — Mon, 13 Dec 2004 18:25:00 GMT

News of Microsofts answer to Google desktop search engine thingy just announced...I'm not much for blogging "info-posts" as you'll be able to find this all over the blogworld in about 10 minutes time but I thought I'd do it to annoy Jamie 'cos I got there first :-P

Scrum Sprint best practices – the missing link

james.simmonds — Fri, 10 Dec 2004 23:25:00 GMT

One of the things of interest to me and the guys I worked with on a recent Scrum project is what happened inside a Sprint and this was brought home on the project review we conducted a few days ago; this area seems to be a hot topic not only for us but for discussion on places like the http://groups.yahoo.com/group/scrumdevelopment.

First, I think I should set a little context for this posting and to provide an insight into my opinions on this. In this article I want to clearly position Scrum, Engineering Practices (the definitive blog on this is here) and outline the approaches you have for how your team works within each Sprint – this being the missing link.

To truly understand what Scrum is you have to be clear that it is a way of improving the delivery of software and not the instructions for developing software – in fact the Certified Scrum Master (CSM) course I attended in London back in July left me slightly disappointed as Ken Schwaber and Joseph Pelrine hardly mentioned anything about what you actually do intra-sprint (remember I’m a developer!). Hopefully I can shed some light on the techniques you should use or consider adopting on a daily basis to maximise the amount of software you build and improve the quality of what you do produce.

Scrum

Scrum, well enough has been written about this so you should know what this is about by now (check out my colleague Steve Garnett’s blog dedicated to Scrum/Agile if you want to know more) however I’ve definitely formed some very clear thoughts on this,

You either get it or you don’t – the team I worked with “got it” immediately – a consequence of us all being old timer consultants looking for something to make our life easier maybe? Who knows? But I certainly get the impression that someone either instantly warms to the opportunity Scrum offers and they seize it or they grasp an element of it but continually revert back to classic development techniques. That’s not to say a sceptic or someone who doesn’t get will never get it but they will have a longer journey to get there. They will have that “Eureka” moment eventually!
Scrum works! Put two teams of identically skilled people/chimps into a project room, one team using a waterfall approach, the other using Scrum and the Scrum team will produce more software, more aligned with the customers requirements then the waterfall team…period!

Engineering Practices

Following on from my Agile Golf Analogy (AGA) I’d like to re-iterate one of the parallels…

“If you want to hit a golf ball further use a bigger club, do not try to hit the ball harder with the same club”

Similarly during a sprint if you want to produce more software then use better engineering practices, don’t push your team harder – it’s just not a sustainable approach. This is an absolute truth. One of the maddest discussion threads I’ve witnessed (and contributed to) on the yahoo scrumdevelopment group was one that started out asking the question “What should a BA do on a Sprint?” and ended up with two of the group’s luminaries having a slanging match over XP versus Scrum. However it did spark off some interesting discussions about the use of engineering practices within agile methodologies and one of the guys actually got pretty close to voicing my take on this.

Engineering practices are,

Misunderstood to represent or actually be an agile methodology.
Not limited to agile software delivery methods – they can and should be used by all development teams irrelevant of the methodology followed to deliver the software – if you are in a waterfall project you will get as much benefit as a team implementing Scrum.
Misnamed in my opinion – they should be called “Engineering Disciplines” – as it takes discipline to use these and serious discipline to continue to use these when the pressure is on.

Process is not a dirty word

“Individuals and interactions over processes and tools” – the first tenant of the agile manifesto and a somewhat unsettling one to the PM used to a command and control environment and a possible barrier to adoption of an agile approach. "Hey Bob, get a load of this...people over processes?...no tools?...have they met our developers?....oh boy - I'm not sure about this...".

A successful Scrum project team should employ processes to deliver the software the customer wants and on time – however they are micro processes as opposed to macro processes (which can be thought of as "Anti-Processes" I guess). The tools are tactical, lightweight and easy to use and ESSENTIAL to allow the team to focus on producing software and not deploying it or documenting it or designing it to the N^th degree.

The emphasis of processes has shifted…traditionally the PM would be ensuring the team were following a strict macro process from project start to finish – what the team did during the time they were involved with their areas (design, implementation, testing) was largely ignored as long as they delivered – the lack of direction and feedback (inspect, feedback and adapt cycle) during this meant that delivery is often delayed with severe knock on consequences let alone the time between project inception and delivery increasing leading to a higher probably that the original requirements are stale. Processes are moving to the implementation team and away from the Project Managers – the team use micro processes during the day and sprint to enable Scrum to work; team member roles and responsibilities are converging.

Micro processes are found all over agile projects – however they are controlled by the people, not for controlling people. An example is the daily Scrum or how a developer approaches a task (testplan, code, test, refactor). It’s a similar case with the tools – they are adopted because they provide serious benefit in a highly specific, granular fashion – this allows best of breed adoption and is a key reason to be afraid of a single tool that claims it does it all – today it might be the bee’s knees but tomorrow it’s blown out of the water by something else. I’d use agile thinking in your approach to tools – the only certainty is change so don’t invest too heavily or lock in to a toolset and steer away from tools that prescribe heavy workflows or processes – they are introducing an overhead you just don’t need for something you could probably solve with a whiteboard.

Putting it together

So Scrum provides a method of delivering a product – it’s not the instructions for building software – in fact Ken highlighted that Scrum was being employed very successfully by architects and event planners – not a line of code, unit test or automated build script in sight! Scrum can be used to manage delivery of nearly anything and is especially suitable for the delivery of computer software.

Scrum regularly delivers software of business value
Keeps the team aligned with business requirements
Allows the business to drive the project, it can be terminated early if requirements are unreasonable and unachievable WITHOUT spending a bundle of money to discover this or it can be terminated because it provides enough functionality and the remaining requirements will not provide ROI.

Engineering Disciplines provide the key to producing more software within a timeframe (sprint) whilst maintaining quality of the product. Unit tests, test driven development, continuous integration and particularly slick deployment mechanisms save time – time that is better spent on implementing features, fixing bugs or polishing the software. Another project team within our company has the build and deployment so well nailed that their testers can kick one off anytime they want with ZERO involvement from the dev team. No one has to stop work and perform this task so everyone remains focused – and that’s a good thing as task switching is cited as a major cause of inefficiency.

Engineering Disciplines allow your team to concentrate on producing software
A good testing framework will allow the team to make changes with confidence. Often the requirements for one sprint impact on code previously written – the team has the safety net of the unit tests to make changes with the knowledge they are not breaking anything.
Can provide an efficient method for deploying your software – a slick build and deployment process means it can and will be used often. Software built and deployed more often allows more testing to happen, more testing will reveal more bugs which you can fix, which will make your product more robust when it ships.
Think of these as the Airbags, Side impact bars, ABS and ESP for your project - sure its fun without them but when it matters you really wish you had them to help protect you :-)

To clarify the relationship between Scrum and Engineering Disciplines...

Scrum is not dependent on Engineering Disciplines
Engineering Disciplines are not dependent on Scrum
Both can be used independently of each other however, regardless of your project delivery methodology you should be investing in Engineering Disciplines anyway.

Acid test

A great test to see if you are really Agile is imagining your customer invoking that option you sold them on – “you can stop the project after any sprint if you think we have built enough functionality to go live with”. So it happens…can you do it? Can you actually say “fine, let me burn the latest build to CD for you…et voila – your software sir”. My experience has shown that this is a very difficult thing to achieve, however the good news is that it’s Engineering Disciplines that can save the day. Granular code supported by raft of unit tests backed up by a zero effort build and deployment means rapid, quality implementation and low “time to tester” cycles.

Best practices

Don’t just “Pair Program” – pair up on other activities like design and comment/pseudo code writing. Often another member of the team has knowledge of an area or technology you are attempting to use so leverage those skills.
Have business domain experts (BDE) readily available and willing to pair up directly with a developer – this is almost nirvana in terms of development efficiency. Your developer becomes a translator of spoken word into computer code – as the BDE talks about a business function it appears before their very eyes! This is lean!
Get your testers to run an informal workshop on testing – if your developers are writing unit tests then they need to be writing effective unit tests and they need to learn what this entails. Writing a single test using known “happy path” values is insufficient.
Get everyone together in the same room. This war room will become the team’s home to do with as they please – make it productive for them, lots of whiteboards and a circular table structure promote communication – communication is the key to the removal of problems and the sharing of knowledge.
Introduce a wiki – this allows the team to document vital project information with minimal overhead…no formatting or style guidelines – this is totally irrelevant – the information is king not the presentation. We had a single dev who did our deployments and this critical path bit us when he was on holiday. So he wiki’ed the build and deployment notes and the next build was done by someone else. They amended the notes to fill in some gaps and this process was repeated until the entire team had performed this task. The result was no critical path and the leanest documentation to do the job.
Create an environment that facilitates fluid team bonds – one day you need to work with Joe, the next with Kate. Get that wireless network installed in the project room so team members can co-locate to work on the problem directly. If they have tablet pc’s they might even be huddled round a whiteboard taking notes that can be immediately send out or they could using a shared software whiteboard with a remote team member – don’t let £50 wireless access point become a barrier!
Approach every sprint as if it’s your last one – this is vital in order to achieve a zero technical debt ethos should the sponsor stop the project at the end of the sprint and ask to go live with what you have.

Conclusion

Combining Engineering Disciplines with Scrum is a recipe for success. Both are simple in concept and both are difficult to do – the rewards though are astonishing so the sooner you start practicing them the better!

Update: I found this article "7 Simple Ways to Add a Little Agile without Going to Extremes" - it expands on some of the benefits outlined above to build a more compelling reason to start using them, well worth a read.

BuildUtilities.NET

james.simmonds — Thu, 02 Dec 2004 18:00:00 GMT

I've been working on putting my SendMSN utility to use on our project build process and have created another utility for those of you that use the MBUnit framework to execute your unit tests. This new .NET console application parses the MBUnit XML results file (or console [info] output lines if using HTML output) and allows you to launch a command based on the success or failure of the unit tests.

This combined with SendMSN means that as soon as the build validation tests (BVT/UnitTests) are run from our SDCBuild script all the developers are MSN Instant Messaged with the number of failed tests and a link to the HTML Unit Test result file - this really is cool as many of our devs have Smartphones or PDA's with MSN Messenger clients so there is no escape!

I have bundled up this MBUnit Result Parser application with SendMSN into BuildUtilities.NET, download it here. The full source and debug build is in the zip and I would strongly recommend you look at the Readme.txt in the Documents folder to get an idea on the command line use for each application.

Let me know if you find this useful, have a suggestion for more utilities to help with your project build process or find a bug.

Cheers,

James

Sending MSN IM messages from the Command Line

james.simmonds — Wed, 24 Nov 2004 15:06:00 GMT

As part of my education on Continuous Integration and automated builds from the ground up I've been playing with CruiseControl & SDCBuild. As a consequence the project I'm working on has a slick automated build process with unit tests being run etc...I've not got as far as getting CruiseControl and code coverage in yet but it's early days and I've got some great help on tap from Howard.

I wanted to add a setup project to the .NET solution so yesterday evening I went to add the new setup project and the solution file was checked out...and the developer had left the office! Grrr!

It got me thinking - if I could MSN the guys on the project with messages at a scheduled time (eg: 17:30..."Check your code in!") and also be able to send them build progress messages from SDC scripts it would be cool! So I wrote a little utility application to do this and you can download SendMSN here (Now hosted on ProjectDistributor.NET, click the 'Source' hyperlink). It's a .NET console app that you can call from scripts/batchfiles/cmdline to send a message to a multiple set of MSN recipients. It's a bit rough and ready but it works ok. The full source is there and I'd recommend reading the ReadMe.txt file in the documents folder for instructions and more information.

I'd be interested if you find this useful and in what context it helps you? Me, I'm going to schedule it on the dev server to nag my team into checking in code before they go home for the day, and just so it targets only the offending developers I'm going to write a little console app to run a VSS status report, parse it for names with files checked out and fire off a message to them via SendMSN!!

Enjoy!

Update: I've changed the code to provide more robust cmdline handling, hopefully won't crash if you stray from the happy path (badly formed cmdline args!). Same download - use the link above.

Update: Finally amended the download link above to point to my ProjectDistributor.NET space

Outlook2003 SMS Add-in (MOSA)

james.simmonds — Sun, 21 Nov 2004 15:02:00 GMT

Larkware turned up this free Microsoft SMS addin for Outlook2003 that allows you to send (but not receive) text messages within the Outlook2003 client.

Great...except I can't get it to work with my C500 smartphone acting as the modem it requires to send the SMS - apparently the "Standard Modem over Bluetooth link" that the c500 provides to the PC does not support PDU format messages :(

As a freebie this would have been great to use - I'm not sure I send enough SMS's to warrant buying something like this software from Jeyo to do this although it's pretty cheap and gets good reviews....oh well!

Mondays, Skype and IIS

james.simmonds — Mon, 15 Nov 2004 14:04:00 GMT

My ASP.NET project failed to start this morning - VS.NET reported that "the web server is not running .NET 1.1" and my web project in the solution was unavailable....hhhmmm. IIS Manager reported the default website was not running and any attempt to start it resulted in an 0x8ffe2740 error code (and no decent message as usual!).

Bit of googling later it turns out that Skype's nicked port 80 off of IIS! Quite how it got it's paws on it I don't know as I haven't changed a single thing with IIS or Skype. TCPView confirmed Skype had port 80 and this blog post pointed me in the direction of the option disabling Skype from using port 80 so all is well again.

It would have to happen on a Monday....I hate Mondays!

What's in your mobile favourites?

james.simmonds — Wed, 10 Nov 2004 12:15:00 GMT

So I got a new c500 and one of the tasks is re-establishing the favourites in Pocket IE - I think I had a few nifty ones in there to help run everyday life - what links do you have that you couldn't do without?

My "killer" link is for the train timetable - what's yours?

Any guesses how many "Mobile Naked News" votes I'll get?

PS: If you have a quick way of sync-ing IE favourites from desktop to mobile then could you enlighten me please?! I have a sneaky feeling that there is a special Favourites folder that gets replicated from IE to PIE...am I on the right lines?