Friday, December 26, 2014

Version control

Don’t write a single line of code until you have a version control system in place

Almost all developers know of at least one version control system (also called source code control or revision control). These systems provide a backup of your work and allow you to dip back into the past to find some lost code or work out where a bug may have crept in. However, with a head full of steam and the desire to get a prototype going to demo to the team/client/world you’ll fire up an IDE and start coding and version control won’t enter your head. Stop for just 5 minutes and get a version control repository running first. This is an insurance policy for a number of things:
  • you have a backup when your laptop dies on you
  • when you decide to tear down a section of code - you can always revert back if you find you’ve gone down the wrong path
  • you can easily share your code and encourage others to assist

Which to use?

There are several contemporary version control systems you could consider using, each with their own benefits. Client-server (or centralised) version control systems maintain a master copy on a central server with a local copy being “checked out” by a client. Generally the server maintains the full version history and the client only accesses a specific version as a working copy. Distributed version control systems (DVCS) don’t require a central master copy and all instances of the codebase includes the full version history.

If you don’t currently use a version control system, the following options are worth exploring as they’re heavily used and well documented:
If you’re able to influence the selection of a version control system, it’d be worth opting for a DVCS such as Git - it has a lot of support and most up-to-date developers have used it.

Hosted services

Historically, developers may have deferred the use of a version control system as these needed to be installed and managed on a server. However, there are a number of hosted services that take away the burden of running your own version control system. Some offer free hosting, usually for open source projects, but also offer paid accounts for closed codebases.

The key hosted version control providers include:

Version control workflows

It's one thing to use version control, it's another to use it effectively - especially when you have larger teams or multiple product versions. Atlassian provide an excellent overview of the most common Git workflows - it's well worth your reading time.

One last note

DropBox and Google Drive are not version control systems for development purpose. They are great systems for sharing documents etc but there’s a lot more development functionality and integration options in a good version control system.

Friday, December 19, 2014


Following accessibility practices opens your system up to more users. That, and it may be a legal requirement!

So your application has a super-rich interface featuring lots of CSS, scripting and hoopy asynch data loads. But how does a visually impaired person “see” all of this? How does a physically impaired person navigate your menus with a mouse? These questions (and many along this line) are likely to go under the radar in your project team unless you have a contractual requirement for accessibility or a person with a disability on your team or stakeholder group. However, accessibility (a11y) is something worth being aware of from the initial stages of your project as designing and implementing accessibility changes for an existing system can be difficult.

There is a very useful side-effect gained by considering accessibility: you really think about fancy features and their utility in terms of meeting multiple audiences. Whilst the technical team may be keen on some eye candy, chances are you could make your system difficult for a number of users. By considering how far you could/should push your UI, you also start to consider the additional support requirements introduced by those nifty effects.

A lot of people came across web accessibility in terms of content. Rules such as “provide useful text with images” and “use HTML elements correctly” were part of many “writing for the web” courses. These content-focussed requirements are still important but rich web-based applications provide more than just content and it’s important to know how to use web technologies in an accessible manner. The W3C Accessibility site provides an extremely easy to read resource for understanding how to build accessible web content and applications. This site should be your first stop in understanding accessibility on the web.

Your team doesn’t have to do all of the accessibility heavy lifting itself. A number of web UI toolkit are developed with accessibility in mind and provide information as to how the various components (widgets) meet accessibility guidelines. For a good example, see the Dojo a11y requirements page - it describes how the Dojo developers work towards accessible user interface components and could help inform any custom UI modules you decide to build.

Friday, December 12, 2014

Wear the hats every day (Part 3)

® Six Thinking Hats is a registered trademark of Edward de Bono

This is Part 3 of a 3-part series.

Let’s quickly remind ourselves of the hats:
  • White hat: The white hat focuses on facts.
  • Red hat: The red hat focuses on feelings
  • Black hat: The black hat focuses on caution
  • Yellow hat: The yellow hat focuses on optimism
  • Green hat: The green hat focuses on being creative
  • Blue hat: The blue hat focuses on the thinking process
Often when I'm working  with teams and individuals I don't formally use the Six Thinking Hats. In fact, I rarely make it explicit that this is guiding the discussion. As a project manager or business analyst I use the hats to guide the discussion, especially to dig deeper into statements. For example, I might be tasked with analysing a process as-is and work towards the future process. The naive way to do this is to ask a group to describe their process/system and then how they feel it could be improved. This is suboptimal as it can gloss over deeper issues and also puts people on the spot. Instead, I might follow a process such as the one that follows.

Stage 1 - Find out what is

I review the project brief and any existing process documentation (White Hat) or ask a team member to individually describe it to me. I may also look into related policies and laws to determine the broader organisational context.

Stage 2 - Understand why it is

I then meet with the team(s) involved and go through the process to determine if the documentation matches reality (White hat). This could run as a large workshop or individual small groups depending on how I feel I'd get the best results (Blue hat). The workshop may use the review of the existing process as its spine but the discussion will lead in various directions, sometimes prompted by me or initiated by participants:
  1. The review may draw out disconnects between the "theory" and the "reality" and the Red hat can help here if parts of the process are avoided or ignored - it's important to find out if people avoid something due to frustration.
  2. The Black hat may also be useful here if people raise concerns about the current process. Perhaps things get through that shouldn't or parts of the process are rushed due to time expectations. These can be cautionary tales that could be handled in the new process.

Stage 3 - Consider the path ahead

I then take a break - maybe for a day or more. This is Blue hat time - a chance to review my findings, reflect on the various parties, perhaps seek clarification on various elements, speak to management about progress, and even prepare some discussion materials such as flow charts. This helps me work out my next focus: improving the process.

Knowing what constitutes "improving" is critical. Does the organisation want to save money, improve compliance, reduce delays etc? Perhaps the organisation isn't sure what's happening "on the ground" and is seeking clarity.

This is also a time to classify the type of process or system you're looking at. If you're working in a highly regulated environment then a new process may be predetermined and focus is on how to gain efficiencies. At the other end of the spectrum you may be in a complex environment that requires you to navigate personal, structural, technical and even social challenges. Knowing the lay of the land before embarking on a journey can provide some "travel insurance".

It's important to also consider the option of not changing anything - the existing system/process may operate effectively or a new system may cost more than any potential gains. This is a "null hypothesis" that predicts that nothing will be significantly changed by action.

Stage 4 - Start the journey

At this point the road will diverge based on your Blue hat thinking and planning. I've rarely found projects match up in such a way that I can just repeat what I'd done earlier - this is why experience, agility and good humour are perhaps the most important skills for project managers and business analysts. Rather than just say "This stage depends on many things", I'll mention some common schemes I employ:
  • The project may allow for a lot of creative (Green hat) thinking and this could let teams work on prototypes and then use the White, Red, Black and Yellow hats to compare and contrast each solution to determine the optimal one.
  • A large stuctural change in an organisation or the industry might be in play and require a lot of Red hat discussions to determine the impact on the people involved. The Yellow hat and the Black hat can then help guide and progress thinking - with the Green hat letting people build new ideas that grow Yellow hat ideas and shrink Black hat issues.
  • Unfortunately the technical solution may have already been selected in a "cart before the horse" approach. In this case you have a "fixed cost" and then use the hats to determine the most effective outcome.
  •  The time or budget available for the project may be less than optimal. In this case the White hat helps you focus on what you know and manage project scope. The Yellow and Green hats can help find opportunities within the limitations and the Black hat helps manage scope.
Lastly, never be afraid to go back to the earlier stages to check and verify your progress. 


That wraps up the 3-part introduction to how I approach the 6 Thinking Hats in my work. Like any thinking skill using the 6 Hats is something you have to do over time so as to find how it best works for you. 

Friday, December 5, 2014

Put on a hat when asking questions (Part 2)

® Six Thinking Hats is a registered trademark of Edward de Bono

This is Part 2 of a 3-part series.

Let’s quickly remind ourselves of the hats:
  • White hat: The white hat focuses on facts.
  • Red hat: The red hat focuses on feelings
  • Black hat: The black hat focuses on caution
  • Yellow hat: The yellow hat focuses on optimism
  • Green hat: The green hat focuses on being creative
  • Blue hat: The blue hat focuses on the thinking process
You can work through each of the hats in any order but it’s more effective when two hats pair up. This isn’t to play each off each other or fall into debate (something your use of the hats is trying to avoid). Rather, the paired hats work well together and you may run the discussion with one hat then review with its pair. The pairing also helps manage the discussion by:
  1. Separating Black and Red hat thinking - this is helpful as many people have decided (or been told) that Black hat thinking is negative thinking. A statement such as “This won’t work as the network team don’t get it” is Red hat thinking and not Black hat. A statement such as “The network team may not like this as it opens up the system too much” is Black hat as it raises a concern that needs to be looked into.
  2. Pairing the White and Red hat so as to help in determining if a statement of discussion is reflecting a fact or a feeling. These can sometimes be difficult to discern so having them in close proximity can help guide us in clarifying what’s being put forward.
So let’s look at the 3 pairings that work well.

White and red

This explores facts and feelings and can highlight areas such as processes that aren’t working.
For example, an organisation may provide an online service that imposes a process on users that reflects the organisational structure very closely. Discussions with users may reveal that, whilst they can use the system, they find the process rather obscure as they’re not part of your organisation. This leads to frustration (expressed with the Red hat) that can help refine the process (White hat).

When looking at new systems being introduced within an organisation, the White and Red hats can help with change management. The new system may introduce a need for re-skilling and new processes and it’s important to determine people how they feel about this and how they can be encouraged to engage.

Black and yellow

System security is a great area for the Black and Yellow hats to pair up. It often feels like developers wear yellow hats (“this great new system really helps us analyse our customer needs”) but the systems administrators wear black hats (“this system looks like it opens up too much information”).

Both statements are important to analyse and having both developers and sys admins wear the Black and Yellow hats gives them the opportunity to share their understanding and can really help a DevOps approach.

Green and blue

There’s an increasing amount of literature around building creativity in organisations and good use of the Blue hat to guide and encourage thinking, rather than debate, can help to tap the knowledge and skills of everyone involved.

The Blue hat helps call back the team when they’re deep in Green hat territory. It’s important to keep an eye on requirements (White hat), possible areas of concern (Black hat) etc but it’s also important not to keep interjecting or you risk breaking a useful chain of thought.

The pairings listed above provide a handy guide to working through the thinking process but there are some areas for caution so always have the Blue hat ready:

  • The Black hat focuses on caution and isn’t a whinge-fest. It’s important to let people express optimistic views without being constantly rained on by someone who (proudly) calls themselves a “Black hat thinker” - they’re more likely to be expressing a Red hat thought. I like to start with the Yellow hat and see what people like then start to explore areas that need a critical eye. The goal is not to be all sunshine and lollipops - it’s to develop an effective solution.
  • Creativity (Green hat) is important and can help an organisation become a leader in their market. However, few projects are a completely blank slate so it’s important to use the Blue hat to make sure that the team references other hats and can justify their actions - management is more likely to support something “out of the box” if you can explain it fully.
  • Whilst the White hat focuses on facts, the “truth” can be a fickle and personal thing. Sifting and sorting Yellow and White hat thinking can be tricky, especially when you’re looking at complex problems.
  • Establishing a common language/definition may be very useful here so that statements can be more quantifiable. For example “improved student outcomes” will have a large range of meaning depending on if you’re talking to: students, teachers, or administration
  • Even legislation (law) may not be easily described as “fact” - especially if it hasn’t been tested. Instead of saying something like “raw data cannot be copyrighted” you may have to settle on a statement such as “raw data is unlikely to pass the 'sweat of the brow' provision of copyright law”. The more definite you can be with your facts, the easier they are to use when referring to them.
  • Some people like to use statement prefixes such as “It’s well-known that…” and “I think we all agree that…” to enforce their point and knowingly or to (perhaps unknowingly) quiet most dissent. It’s important to check across that group if it is indeed a fact (White hat) or a feeling (Red hat). Both are important so don’t dismiss the statement - it needs to be categorised and noted - throwing it away is likely to motivate the statement’s originator to try to undermine the discussion.
In the next (and final) instalment I’ll offer an example of how I use the Six Thinking Hats in my work.

Wednesday, December 3, 2014

Workbench blog

I've just kicked off my Workbench blog with a post about setting up a diagnostic HTTP server. I've rounded up a number of coding items I've been doing and aim to get a post describing each one - perhaps you can use them in your work.

If you look at the web version of this blog you'll see a link to Workbench and also Steam - a web album for me to share various locomotive and industrial miscellany.

Lastly, if you ever want to contact me, Twitter and LinkedIn are good starting points.