New One

More tea vicar?

- 1 Jan 1970

Hone those requirements

Good systems come from good requirements. Developing software can either be like flying through the air or wading through treacle depending on the state of the requirements. If developers are having to scrabble around for information or documentation has become stale, delivery time will be adversely affected.

Ensure the documents and data in the project management tool are reviewed regularly so that developers can hit the ground running and keep development velocity at maximum.

- 19 June 2020

The mythical five minute change

How familiar does this sound - you're getting towards the end of a sprint/development and your project manager comes over with a "quick win". The analysis hasn't even been done but the change looks so small and insignificant that everyone has already agreed - it MUST be a five minute change.

A quarter of an hour later - having explained the five minute change, they leave you to it.

The change is of course simple enough. You could grab the code and have it done in that time easy, but...15 minutes have already gone.

So you write the unit tests - more time. Explain it to the test team - more time again. Documentation, builds, screen shots, emails, tweaks, refactoring, fixes, regression testing, release notes, triage, UAT, sign off.

Meanwhile the agreed changes are ready to ship and are being held up by the five minute change working its way thru the pipeline. A meeting is hastily arranged and it is agreed - the five minute change has wasted too much of everyone's time and must be shelved in order to meet the release deadline.

Some quick win...

- 18 November 2016, Edited 18 January 2018

On code regions

On the face of it, code regions offer a fantastic way of organising a large body of code. However, tools such as StyleCop now fly in the face of such conventions and they have fallen out of favour somewhat with the Visual Studio community. So let's look at some of the reasons why this may be the case.

Having to unhide code every time you open a code module is a colossal drag. Even if you unhide the code in one step, that is still a manual process we could do without.

Code regions are not code - they are merely there as comment blocks and so add to the text in a code module without really adding anything.

If you're having to slice the code up in such a way there is a good chance the class is doing too much. Even if you're absolutely sure this isn't the case, there is often a much better way of splitting the code up such as partial classes.

Code can be grouped by some criteria that may have been obvious to the programmer when they wrote it but has been lost in the mists of time. Now new code either gets added to the wrong region, gets added to a "Misc" region or sits outside of code regions entirely.

Code regions have on occasion been abused in the past to apply meaning to poorly named methods and member variables. Clearly meaningful names are far preferable to code regions.

In summary, the case for code regions seems to be getting smaller by the day. In the case of legacy code, there is little mileage in trying to unpick the various regions unless a code module is being revisited in which case the BSP principle may reasonably apply.

Certainly for things like UI design code in winforms and perhaps some for some bespoke framework code, methods and member variables could do with being kept together rather than sprinkled throughout various modules.

Having taken all of the above into account, there may still be cases where code regions can help but these should now be very much the exception rather than the rule.

- 25 July 2016

Test number one

Among the clamour to get software testing done, be it unit testing, ticking off the requirements and making sure the thing is performant and secure - something critical to the success of a development is often lost. What do your users think about what you are developing?

Good as the voice of your user is - be it a developer, manager, user rep or (if you're lucky) a business analyst, nothing will give you honest feedback of your efforts faster than users.

If you don't have a testing function then something that can often happen is that developers test mainly on the happy path or with a certain set of data. Corner cases and more exotic scenarios can get missed.

So, users then. Firstly - they're not all created equal. Some will live and breathe your software, some will use it occasionally and others for some ancillary activity such as reports or sense checking another system. Get as many user types as you can to eyeball your product. If they're not happy with it, then let's be clear: you have failed the first and most important test. It doesn't matter if it goes like stink and has a bucket full of cool design patterns under the hood - if it doesn't do what they need it to do then it is the software equivalent of a paperweight.

Do not underestimate the lengths users will go to if they find your software buggy or awkward to use. They'll work round it, use other software, hack files and exploit features not intended for that purpose.

Even worse, some poor soul who has become used to all the creases and niggles can become the sacrificial lamb - the go-to person for everyone else. This is good in one way, but this person then becomes the de facto voice of the user and chances are, they'll gamely try and use whatever you put in front of them because at the end of the day, they need to do their job.

Get to know your users. Don't assume you know their job better than them. Build rapport. A happy user base is like a few thousand added to your salary. The job is just so much easier if they're on board.

- 13 July 2016