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.

Sunday, November 30, 2014

Try on the thinking hats (Part 1)

Instead of judging our way forward, we need to design our way forward. We need to be thinking 'what can be', not just about 'what is' - Edward de Bono
® Six Thinking Hats is a registered trademark of Edward de Bono

This is Part 1 of a 3-part series.

After several years of working long hours as a programmer I went into teaching - it was my interest in learning and problem solving that motivated me. As developers and development teams we engage in learning throughout our careers but primarily in terms of "technical skills" rather than "meta skills". These meta skills focus on areas such as how we learn and how we engage others to help us achieve goals. I've worked with many people that I would class as excellent developers. These people can solve coding problems quickly and elegantly but I've noticed that they often do so with blinkers on. As teams engage in agile approaches to projects it is important that they engage more closely in understanding the environment in which they are working.

Whilst studying and then working as a teacher, the skills around thinking and the area of metacognition became a primary interest to me. One well-known strategy for guiding thinking is Edward de Bono's "Six Thinking Hats" - first published in 1985. The six hats provide an enduring method for framing how teams can examine problems and seek effective solutions:
  • White hat : The white hat focuses on facts.
  • Red hat : The red hat focuses on feelings
  • Black hat : The black hat focuses on caution
    • Be careful with the term "black hat" as it is often aligned with negativity
  • 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.
Some people react badly to the six hats approach but it's important to understand what's causing this. Here are a few examples worth considering:
  • "This is just new age mumbo jumbo"
    • Some people really like to argue and anything that sounds like they won't be able to push their idea threatens them. The key risk with these people is that they believe the loudest argument is the strongest argument. Encourage these people to engage but be definite in adhering to the process - calling out when they're trying to dominate.
  • "This will take too long"
    • Some people feel that it's quicker to "work out the answer and go for it". Unfortunately this is often a form of "shallow" problem solving - they haven't really worked out a good answer and, usually, they've focussed on the technical aspect and not the whole issue. I've found that the first answer, once put under scrutiny, starts to fall apart quickly and, if the team had started development, a large amount of time is wasted in code.
The best approach to handling criticisms is confidence. Make sure that you are comfortable with the six hats and that you keep the group on task. Don't be afraid to cancel the session if a participant just won't cooperate - walk away, put on your blue hat, reflect and look at approaching from a different angle. Avoid the following to help retain purpose:
  • Don't make people wear a hat as it can reduce the session into a side show.
  • Don't allocate each person a specific hat for the session as the group should be working with the same hat at any one time.
  • Stay "on hat" by parking comments that fall under a different hat. Note the point on a whiteboard and direct the group back to the current hat.
  • Monitor the highly assertive group members. Not everyone likes to proactively put ideas forward but, assuming you have a good team, encouraging the whole team can lead to solutions that the loud mouths never thought of.
The Blue hat is very useful when planning a session with an individual or a team. You don't have to use all of the hats in every session, indeed it can be very useful to focus on a single hat.

One example is when reviewing a workflow: the White hat is really useful as you just want to know what the steps are and who carries them out - later on you could arrange a session that uses other hats to focus on issues such as problems with the workflow (Black hat) or improvements to the workflow (Green hat).

In the next article I'll look at how you can use the hats in a pairing arrangement to help you to direct your questioning during analysis work.

Further reading