Carly Richmond

The Seeker

Evaluating Data and Exception Driven Workflows in UI Design

New year, new start. January brings news of resolutions into our conversations and social media feeds. Brought on by last years triumphs and tribulations, we use data to inform how we should improve in the upcoming year. Deriving meaning from the events of the prior year if you will.

With a new year, people seek resolutions to improve meaning and effectiveness of their lives

The majority of systems I’ve developed over the years are data-intensive. Past and present design considerations affect how users process information and achieve their goals. With the start of a new year, I reflect on data and exception driven workflows, reflecting on their differing usage and future impact.

Where Do I Hide?

Historically, I’ve witnessed development teams providing expansive grids of data for convenience. To the extent that I’ve recently discussed the need to consider visualisation alternatives in our systems. Exposing all data columns a user might need to see at some point does reduce time to market for clients. It allows us to throw grid controls or Business Intelligence software on top of sources without giving much consideration to how data is actually used. This introduces unintended challenges into business processes.

Exposing all data increases cognitive load on making decisions and reacting to events. Originally, engineers exhibited good intentions to allow easy analysis and flexibility of transforming data by varying dimensions. Seeking context and identifying patterns is not always acceptable. Where results dictate a call to action, users exhibit a higher cognitive load. A data driven workflow introduces the need to constantly validate decisions. For new joiners, such processes require the accrual of knowledge over time to master business processes.

Care should be taken to identify key user goals over throwing grids and BI software over data and forcing users to dig through their data

These challenges teach us that presenting all data fields is not always the right approach. Good engineers should be comfortable asking questions and forming an understanding of the processes clients follow, and the goals they strive to achieve. Developers should collaborate with users and designers alike rather than wait for permission to try something new.

Tell Me a Tale

Notification-based flows are a viable alternative to presenting vast expansive grids of data. If users are seeking answers from our data, there is no reason the system cannot present the answer itself, thus informing users of what action to take.

This does address the minimum knowledge requirements of a data driven application. New clients can begin using applications from the beginning without a significant fear of making mistakes, or executing particular actions in the incorrect order. Dedicated engineers should focus on alleviating the cognitive load of users. Reducing training overhead of our users should be a key considering in our product strategy.

Notifications, in moderation, can help users identify actions far more easily than searching through datasets

Designing such a workflow introduces challenges. One key threat to user adoption is alert volumes. The possibility of cognitive overload remains unless caution is not taken to send correctly targeted alerts. Notifications should only be sent to the intended audience. Understanding of the target population can help identify subscriptions to reduce the cognitive load for all consumers.

Migrating from manual procedures to automated notifications relies heavily on trust. Stakeholders need to be satisfied that the system generates the correct decision. Having comfort in the underlying data is a critical starting point. Only then can we construct a reliable notification based approach.

Citizens of Tomorrow

Creating an alerting mechanism is the start and not the end of the automation journey. Once notifications have been identified, there is no reason that the risk of manual error could not be eliminated by automating the corresponding action.

Regardless of the benefits of automating repetitive manual steps, false positives and negatives will affect uptake. Especially in heavily controlled environments where incorrect decisions result in potentially disastrous consequences. Humans will begin to disregard particular alerts if regularly presented with false positives.

Recent experiences using automated tickets got me thinking about the desensitisation of users to false results

A recent experience over Christmas vacation with mobile ticketing brought home the potential impact of such false results. My husband’s bus ticket always failed to validate. The reader emitted an angry beep every time he boarded a bus. Every time without fail, the driver would roll his eyes and wave him through. It became vastly clear that false negatives were such a common occurrence that negative validations were always dismissed as invalid.

Failure to strike the balance of these false results against true negatives will erode client trust in the system. Confidence in both the workflow and action automation can only be built through validation and measurement of commonly agreed KPIs. Yet another case where collaboration between software engineers and users is the sole solution to building solutions that address client problems.

Thanks for reading!

Grand Designs

Challenges Integrating Design Thinking and Agile Development Practices

Have you ever seen rabbits in the clouds? Or perhaps a face in the flames? Psychology dictates that in our constant search for patterns, humans look for context and meaning in the most insignificant of constructs.

There is an element of order in building software. Design and architectural patterns help us avoid the same old pitfalls. The old ways must make way for new inventions. Out of the box thinking is the sole method of solving new problems. Mechanisms that encourage innovative thinking can stop us seeking patterns and ignite ingenious ideas.

Can Design Thinking encourage out of the box thinking and integrate with our Agile development practices?

Design Thinking is regularly touted as a process for the development of innovative solutions by designers. Yet integration with software development practices are critical to ensure the successful adoption of the solution. As we embark on our latest development journey, I ponder the potential for integrating Design Thinking and Agile practices, reflecting on my recent readings and challenges.

Think Again

One key concern with utilisation of Design Thinking is the premise that it allows definition of a full solution upfront. Locking in every requirement upfront, regardless of the published format, doesn’t allow for lessons to be learned.

Design Thinking and Agile methodologies can encourage iterative design and development

As illustrated above, Design Thinking is an iterative circle, not a fixed length line. It doesn’t have to be weeks of upfront workshops. Iterative development must start from the beginning, in the empathy stages. Some teams have had success with using Sprint Zero workshops to establish common ground and agree the required high engagement levels between technologists and business. Where all parties identify the challenges and the initial story set sounds like an ideal compromise.

Utilising a cyclic method in both Design Thinking and Agile practices allows not only the product definition to evolve. Knowledge of user processes is not static. Our education undergoes peaks and troughs not only as features are adopted, but also as they change to address new challenges. Having an initial empathy gathering stage prevents the identification of additional walls that are built as user processes mutate.

Think How It’s Gonna Be

There is a common misconception that exercising agility means you are mindlessly react to new requests. Some think it is a reactionary journey, where teams take every turn on the route, rather than driving straight down the motorway. At times I have felt our journey has turned into blind country backroad turns taking us further into darkness.

Building a solution to such complex business problems needs us to understand where we are going and how it will solve our clients problems. A product strategy serves as the GPS on our Agile journey. Identification of challenges and high level themes using the empathy and define stages. As stated previously, precise stories can be defined over time in line with our goals, over an initial big bang approach.

The Hills format designed under the IBM Design Thinking format does look rather familiar…

The definition of hills may provide a mapping between these processes. Recent reading this week helped me discover these tools for defining the identified problem, with a corresponding user outcome. Peering at the above example, doesn’t the who, what, wow format appears surprisingly familiar to our favourite user story format? Given this similarity, formulating a journey using user story mapping techniques can help you identify a product strategy.

Think of Tomorrow

Designers are often the primary facilitators driving Design Thinking processes. A common challenge discussed online is how to foster collaboration between software developers and designers. Programmers, designers and business users alike all speak different languages. Nevertheless, early engagement with all three parties will establish the required communication channels.

While formulating blue sky ideas, sometimes we need to keep out feet closer to the ground and focus on technically feasible solutions

Although blue sky thinking is important for ideation, how do you assess the technical feasibility? In the dream evolutionary paradigm, new ideas to solutions will need to integrate with the existing software.

By excluding technology from the table, technical feasibility of any solutions is not considered. Designers and users require early engagement from technologists to help advise on the product details pre-prototyping stage. Software engineers need to meet them half way to collaborate to build the best possible product.

Think it Over

We have been travelling down the Agile road for several years now. Clearly this is the start of our ongoing journey with Design Thinking. Musing over any identified obstacles in our software development has always helped us employ continuous improvement. Ownership of your process means we must strive to make things better.

Be mindful of the walls being built between technologists, clients and designers, and break them down

Integration with Design Thinking has presented blockages in our process as we wait for stories to begin prioritisation. Regardless of the above musings, it is vital to consider this the start of the road. This is a great opportunity to learn best practices of design to improve system workflow.

Collective ownership by clients, software developers and designers is vital to ensure the success of our latest endeavour. Continuing the conversation will ensure we address some of our challenges in defining our solutions together.

Thanks for reading!

Space Oddity

The Importance of Breathing Space in Software Development

Writing code is a pretty thought intensive activity. Breaking down the individual steps, reviewing API documentation, testing and debugging as you go. We switch between some pretty intensive tasks. The satisfaction when the problem is solved is indeed thrilling. Any factors that impede these steps will prevent engineers yielding the desired results.

I have seen first hand how work environment can affect developer productivity. Engineers in our environment are still using noise cancelling headphones to ensure the ability to become engrossed in their work. The state of their calendar is another influencing factor that should be explored.

Whether we are collaborating or working alone, we need space in our schedules to be productive

A recent catch up with a colleague got me thinking about space. They were very frank about how extending free time in their calendar caused their productivity to thrive. To mark my thirtieth blog post, I reflect on how space has contributed to my own productivity over the course of my career, and how my tactics to focus on deliverables have evolved.

A Sky Full of Stars

Back in the good ol’ days, the ratio of scheduled meetings to space in my calendar generally favoured the latter. Measurement of my productivity was the development of features. In the majority of my early projects, meetings were reserved for key updates only.

Scheduled meetings are a big productivity killer when the time compared to unscheduled time tips the scales. Especially if there are many with small gaps between them. Keeping meetings to a minimum is required for developer productivity to thrive.

Some may think stand ups tip the scales on too many meetings, however my own experiences have found them to be a far lighter touch

I’ve seen differing attitudes to the number of meetings dictated by Agile methodologies such as Scrum. Some consider the number of meetings too frequent, or a surveillance mechanism to monitor developers. I recently reflected on different experiences, where under a waterfall model I was subjected to a myriad of update meetings that impeded my own deadlines. This is a clear example of how such a lack of space to code affects developer deadlines. Becoming engrossed in a coding tasks only to switch out thirty minutes later will affect the quality of any code submitted for review.

Supermassive Black Hole

Minimum meetings not only produces programmer productivity. In my early career, it allowed me to build a reputation for reliable delivery. It also granted me the opportunity to develop expert knowledge in the technologies I used daily.

Once in a position of knowledge, you are faced with two options. The first is to keep your cards close to your chest to ensure a dominant position. The second is to disseminate that knowledge among colleagues to ensure a long term strategy. While the latter is always the best option, it has presented me with challenges on an old high profile project.

Imparting knowledge to less experienced colleagues is a legitimate, productive task that should be given equal weight to coding

Providing training is not always a scheduled classroom activity. The majority of training we receive is as part of the daily grind. More commonly it is ad-hoc conversations as developers encounter issues with their own deliverables. As an oracle of expertise you need to embrace that providing on-the-job training is a valid pursuit.

Good managers will protect inexperienced engineers through use of office hours, where it makes sense. Developers will not opt for such a solution. They will aim to please as their own individual items start to suffer. Specific knowledge sharing meetings have been the right call in half of the situations that I’ve encountered. Then again, spending all day training and all night coding is, in hindsight, never the right call!

Starman

Transitions to senior engineer and manager makes space harder to find. Measurement of your success is no longer dependent on the code you write, but the features delivered by others. Quickly you become a facilitator, rather than a technical contributor.

This is certainly true in my case. I did touch code this week. Shock horror! However, my commits are often small tidy ups to improve software quality. The ratio of meetings to space very much lies in the former camp now.

Dedicated thinking time, be it for code, slides or just getting stuff done, now has to be scheduled for me. Fake calendar entries are a great mechanism to allow me to achieve that.

Even leaders need gaps to support developer productivity

The lack of gaps in my calendar are vastly becoming an ongoing joke in the office. To be productive I also need space to support and guide developers when they need it. All my hours need to be office hours. Not just a couple of dedicated sessions per week. No matter how senior you get, you need space in your calendar to get the job done. The question becomes whether it is explicitly scheduled or available freely.

Thanks for reading!

Start Me Up

Managing The Pitfalls of Persistent Testing Environments

Despite living over two hundred miles from my immediate family, I have always been called upon as dedicated tech support when gadgets go wrong. I can regale many stories of fixing PCs, printers and mobiles on family visits or over phone calls. The age old strategy of switch if off and on again or some variant has proven to be successful most of the time.

Similar tactics are employed to keep some of our persistent testing environments alive. I dream of a day where we no longer exhibit a reliance on permanent testing environments. The ultimate fantasy would be for all services, queues and any other infrastructure to be spun up and down at the click of a button.

Managing our legacy testing environments is like trekking through an overgrown and unfamiliar jungle

While we have made significant strides in some of our newer microservice components, our legacy applications fall far short of this goal. To this day they are reliant on physical infrastructure that cannot yet be created on demand. Here I reflect on past and present challenges of maintaining our legacy testing environments, and the effects on team productivity.

Constructing the Connection

Accommodating connected systems has been the greatest complication of late. Working in a large multinational corporation introduces many challenges on agility. In the midst of our current transformation, adoption of agile techniques is taking time to permeate through the organisation. While the message echos through the grapevine, we need to engage with traditional waterfall teams and Agile evangelists alike.

In large Agile transformations, opinions are changed via grapevine whispers as it ripples through the organisation

Managing upstream applications with less frequent releases means also managing their expectations on our testing environment availability. If their instance is up and running for three months to support a long laboured testing cycle, their default expectation is ours must also be continually available for the same period. This manifests itself in urgent, short notice requests that are expected to be fulfilled, fostering frustration among our developers.

Communication channels need to be well established on both sides for this relationship to succeed. Striking a balance between facilitating their testing as well as our own is critical. Agreements on notice and availability of our testing environments have only just been established. The jury is out to measure the effectiveness of these SLAs. Only time will tell if our ongoing strategic transformation will better support all applications.

Inside Out

The outside perceptions are important. Looking to the inward affect on team productivity has provided some fascinating observations. Despite having support rotations to ease the burden, fixing fractured environments does often fall on teams testing features. Obviously production takes precedence. Regardless, even a short stint of fixing testing environments that break every few days is far from satisfying.

Automated deployments only get us so far. Without collective ownership and automated verification techniques, shared components can be left in a broken state. Nothing breeds animosity more than feeling you are continually firefighting issues introduced by another squad.

Hitting the reset button restores order for a little while, at the expense of building engineer expertise

Introduction of the reset button process to refresh the environment has addressed many of these issues. An unintended side-effect has been engineers are less likely to investigate and diagnose issues before applying the fix. Mentoring by more experienced engineers addresses knowledge gaps. Nevertheless, instilling the same level of ownership by senior developers takes far more time to transfer to more junior programmers.

Stop Breaking Down

Continuous improvement is an imperative technique for addressing the trials of our testing environments. The aforementioned reset button and communication protocols with other teams are great strides forward by the team. These small increments should be nurtured by managers, and balances with delivering of client features.

These changes can only go so far. A legacy system will remain legacy without significant intervention to reduce the behemoth of technical debt. Microservices and utilisation of container frameworks can be used to better scale solutions. Nevertheless, this solution should be used with caution to avoid creating a distributed monolithic monster.

The legacy application monster will continue to live only until we commit to the significant intervention to eradicate technical debt

Infrastructure such as queues and databases are the greater challenge to address. Large organisations need to invest in technologies for generating full application environments, including communication and persistence layers. Replacing the reset button with start and stop will cease with ongoing productivity killer that is our testing environments.

Thanks for reading!

Bad Reputation

How Poor Leadership Taints Software Development Practices

Everything evolves. Technology is a common example of the ongoing digital revolution, with new frameworks and languages appearing at a constant pace. The field of how we engineer software is also changing, with new practices and techniques being defined every few weeks. Agile has existed in name form since that infamous conference in 2001. Since then opinions on it’s adoption have existed in equal measure.

I’m fortunate enough to work with engaged colleagues who read as much as me. A recent find of a 2015 article on abhorrent Agile techniques, including some aspects of Scrum by one of our team has caused considerable debate in the office.

The entry is… interesting. It certainly lives up to the initial disclaimer of rants, essays and diatribes. Some points such as the affect of open plan office spaces on work rate align with my recent musings on the affect of workspace on developer productivity. Other musings raise valid concerns of the deprioritisation of technical debt over user features, which can be a symptom of poor craftsmanship.

Weak leadership will derail software delivery, regardless of whether Agile or Waterfall practices are adopted

The main premise of this article is to call out how terrible Agile, and Scrum in particular, are without proposing alternative solutions. Digging into the details, I find the article to be an unfortunate symptom of bad experiences. Here I reflect on my experiences of developing software over the last seven years in Agile and Waterfall environments. Not to rebut, but simply to highlight how weak leadership can taint practices within software development.

I Want You

The Technology industry has greatly suffered from sweeping statements regarding developer stereotypes. The quintessential developer that people imagine is still the pale antisocial guy sitting in the corner furiously typing away late into the night to create his vision.

Programmers tend not to be great at managing clients. We’re very literal people. We like systems that have precisely defined behaviors. This makes working with non-technical people harder … because we tend to take every request literally rather than trying to figure out what they actually want.

Michael O’Church, Why “Agile” and especially Scrum are terrible

Long gone are the days where programming is a solitary occupation. Working with people, technical or not, is a challenge. We are all fundamentally different. In business driven domains technologists may speak the same language, but ideas can be presented differently based on the individual. Jargon between different frameworks and languages contribute to these challenges. Our recent games of discussing Angular and REST services are a classic example where engineers themselves are speaking different languages.

Coders need to choose collaboration over solitary programming to build software

Clients have diverging opinions on what features they want. Fostering curiosity in engineers is vital to encourage them to figure out what users want. Our strongest developers sit with our clients regularly and observe their processes. By understanding the process, and the technical possibilities, those engineers propose great solutions to the problems our users face. These ideas often differ to the stated client request, and have often been accepted as the preferred solution. Leaders will encourage such collaboration, and see that this time is better spent than daily pinning programmers to keyboards, expecting a churn of N lines of code per day.

Wherever You Will Go

Product strategy is an often overlooked concept in both the Waterfall and Agile projects that I have worked on over the years. I’ve had different successes and failures utilising both paradigms. This needs to be balanced with smaller, more manageable deliverables.

Corporate Agile, removed from the consulting environment, goes further and assumes that the engineers aren’t smart enough to figure out what their internal “customers” want. This means that the work gets atomized into “user stories” and “iterations” that often strip a sense of accomplishment from the work, as well as any hope of setting a long-term vision for where things are going.

Michael O’Church, Why “Agile” and especially Scrum are terrible

I’ll admit the strategy surrounding the product is often obfuscated from developers. I’ve been fortunate to experience empowerment to write user stories collaboratively with users that provided an explicit benefit. However, with both paradigms I have experienced lack of clarity on what the wider goal is, and what the roadmap is to achieve that goal.

A transparent product strategy ensure we all competing in the same race

One historic project I worked on managed in a Waterfall fashion simply had a goal of automating calculations, with no strategy to exposing users to the results. This was partially down to a refusal to adapt to change, resulting in an unsuitable solution being presented months down the line. In comparison, our early Agile experiences resulted in lots of small, useful features being delivered in a matter of weeks that combined didn’t form a cohesive workflow. Talented leaders will foster an element of purpose to promote passion among programmers using a defined product strategy.

If your firm is destined to be business-driven, that’s fine. Don’t hire full-time engineers, though, if you want talent … Good engineers want to work in engineer-driven firms where they will be calling shots regarding what gets worked on, without having to justify themselves to “scrum masters” and “product owners” and layers of non-technical management.

Michael O’Church, Why “Agile” and especially Scrum are terrible

Successful technology solutions become ingrained into our regular routines. Early innovations at PARC labs on smaller devices established that their success is dependent on their usage becoming knitted into the fabric of daily life. Our strongest developers understand user needs as well as the technical challenges. When they leave, they take that knowledge with them. As leaders it’s important for us to retain our full-time talent. Hiring consultants will help us address technical challenges, at the expense of understanding client needs.

I’ll Be Watching You

No one wants to feel micromanaged. Agile is advertised as fostering collective ownership among developers, over the traditional top-down management profile of Waterfall. I’ve had differing experiences of adoption of nanny-state surveillance by managers.

Scrum is sold as a process for “removing impediments”, which is a nice way of saying “spotting slackers”. The problem with it is that it creates more underperformers than it roots out. It’s a surveillance state that requires individual engineers to provide fine-grained visibility into their work and rate of productivity.

Michael O’Church, Why “Agile” and especially Scrum are terrible

Levels of supervision depend on the levels of trust exhibited by leads. One of my last frustrations of a Waterfall project was the sheer number of status meetings I had to attend to satisfy the obsessions of the Project Manager and Technical Manager. Deliverables were severely impacted as we spent more time talking about our deliverables than actually producing them.

I’ve found management keep a far more watchful eye under Waterfall development than in teams where Agile has been adopted

By comparison, my experiences of Scrum and Kanban have been far lighter touch. Stand ups are more around communicating status and voicing blockers. I can then engage with colleagues to remediate any problems. The culture of these two teams has had more of a contributing factor in my experience than the software management paradigm.

No Silver Bullet

Across all Software Development techniques, there is considerable debate on the best approach. Large organisations prefer to establish a one-size-fits-all approach to software development. It’s human nature to want to facilitate receiving what we want more quickly.

Scrum is the worst, with its silliness around two-week “iterations”. It induces needless anxiety about microfluctuations in one’s own productivity. There’s absolutely no evidence that any of this snake oil actually makes things get done quicker or better in the long run. It just makes people nervous. There are many in business who think that this is a good thing because they’ll “work faster”.

Michael O’Church, Why “Agile” and especially Scrum are terrible

Expectations do need to be managed to ensure clients don’t expect you to deliver the world. We did have experiences with Scrum initially that we delivered more features faster, which won user favour. Nevertheless, the need for space was spotted quite soon to ensure engineers had learning space. Otherwise, you establish an inconsistent work rate, with effort upticks immediately before and after releases.

Although agreement would allow standardisation of development practices, neither Agile or Waterfall are the silver bullet that we have been looking for to defeat our development demons

We found Kanban to be more effective at establishing a constant rate. This prevented team burnout in our case. Other teams in our area still prefer Scrum, as they haven’t had the same cadence challenges.

Engaging with technical and non-technical colleagues alike is important to evolve your development techniques. Brooks stated that there is no silver bullet to solve the trials of software engineering. Neither Waterfall or any Agile methodology will fit every use case. Leaders need to trust teams to establish the techniques to take down the monsters taunting their development processes, using many smaller bullets.

Thanks for reading!

Beyond the Great Divide

Encouraging Developers to Cross Platform Divides

The comfort zone is comfortable for a reason. Feeling content, engaged and productive is a thrilling experience. If we’ve ignited passion in our programmers, you’ll see their fingers dance eagerly across the keys. Developers become complacent with not only particular technologies, but specific platform components.

If you always do what is easy and choose the path of least resistance, you never step outside your comfort zone. Great things don’t come from comfort zones.

Roy Bennett

To address our recent bottleneck and design challenges, I’ve been reading Your Code as a Crime Scene by Adam Tornhill. One clear challenge described early in the book is that engineers struggle to reason about the entire system. This is a difficulty we are finding as our platform starts to scale more widely. Here I reflect on our own experiences of encouraging developer laser precision on parts of the system, and how it has impacted platform performance.

We have encouraged programmers to exhibit laser precision over the components to which they always contribute

Bridges Crossing Rivers

As I alluded to before, engineers are building knowledge of only a part of the system. This is partially a symptom of the myriad of microservices that we have constructed over the past few years. Our architecture has made it easier to decouple services and create new features. Nevertheless, delivery pressures result in our engineers persistently touching the same services. Reasoning about the performance of the entire plant becomes impossible.

It’s vital that we encourage engineers to cross component bridges and develop knowledge of the entire system

Our team is not the worst for coupling programmers to components. Several developers have migrated across domains. Such moves are normally a reaction to increased project demands in a particular area. In such circumstances, experienced engineers are utilised over junior developers due to time pressures. These rare occurrences have grown more experienced developers into leaders. What is the effect on junior developers?

This preference can introduce poor design into components when junior developers do not receive appropriate mentorship. Component design can become bloated, impacting performance. Giving all developers experience of other parts of the platform provides them with the guidance they need to better design performant microservices. To grow our entire team and platform, we need to make better use of rotations.

Another Spin

Through the grapevine whispers that other organisations are better at utilising enforced rotations echo. Reflecting on a talk I attended back in March reminded me of one particular example.

As part of their adoption of Extreme Programming practices at Pivotal, Elisabeth Hendrickson discussed mandatory rotations. Combined with pair programming and other XP techniques, they have found great benefits to their product development. Enforced rotations expose engineers to different projects, teams and technologies.

Leads need to be proactive in rotating engineers across projects, technologies and teams

I’m tempted to consider more regular rotations by our engineers. To adopt a similar approach, we must determine how often should developers rotate? Like sweet and salt popcorn, a balance must be maintained to ensure people have space to learn, while ensuring client features are consistently delivered.

The Tender Trap

We should be growing our workforce to allow them to become adaptable. Building their transferable skills will prevent technologists being trapped in a particular domain. Seeking single technology skilled developers will also prevent them building expertise across all systems that we build and support.

It’s more important to employ curious engineers that can investigate technologies and system components than be the best coder in technology X

An emerging trend discussed at a recent conference was the need for organisations to evolve their hiring practices. Our historical strategy of employing Java experts to write Java, or Angular developers to build Single Page Applications will not scale. Employing engineers with intrinsic curiosity can aid us in nurturing cross-component experience. Fostering the ability to learn new technologies, architectures and performance evaluation techniques will make for productive platform-wide programmers.

Thanks for reading!

All the Small Things

The Importance of Perks in Developer Workspaces

Loss is inevitable. Be it an opportunity or my friend’s elusive bank card, humans experience loss throughout their lives. Reactions differ significantly. Often, attributes are based on personality and the perceived worth of the offending lost item.

Losing rather than gaining an incentive is more likely to have colleagues apply the brakes and question a decision

It can be surprising how significant the little things can be. I’ve discussed example agile workspace features and their affect on productivity previously. The recent movement and replacement of the comparatively lavish coffee machine with the default model had an unexpected reaction among some colleagues. This week I process how loss affects retention, and consider the importance of retaining incentives in our office environment.

Loss of Control

Confession is good for the soul. It is time for me to come clean. A subset of people, including myself, knew the coffee machine was going to be moved. We harboured the secret that it was no longer going to be accessible by Technology personnel on this floor.

At the temple there is a poem called "Loss" carved into the stone. It has three words, but the poet has scratched them out. You cannot read loss, only feel it.

Arthur Golden, Memoirs of a Geisha

It all came down to expense and lack of empathy. Unbeknownst to us, engineers were walking across the floor just to use the nicer coffee machine. Therefore, when it was gone, it caused an upset to their routine. Even the most spontaneous person doesn’t like an unexpected change to their schedule. Feeling their frustration was needed to action a replacement.

Rapid Hope Loss

I’ve been seeking differing opinions while awaiting installation of the replacement machine. Sympathy from friends who don’t enjoy such perks was especially hard to find at a recent brunch. It is difficult for them to empathise when they have nothing more than a hot water tap. Or in the case of another friend where they banded together to buy their own machine and pods. Understandably, developing an affinity for something you don’t have is challenging.

I’ve found unexpected insight at a conference this week. A talk on designing financial software systems using behavioural science to be exact. The speaker noted changes made to the Italian Driving Licence points system and their affect on driver behaviour. Moving from an incremental to decremental model resulted in a significant reduction in the number of speeding offences. Losses are far more impactful than gains.

Losing rather than gaining an incentive is more likely to have colleagues apply the brakes and question a decision

With humans being perpetually pessimistic, it’s now no surprise that such a strong reaction occurred. No one wants to be treated differently. In large organisations that includes across other divisions. Despite the antisocial stereotype, engineers are humans. Just like accountants, HR, testers and anyone else employed by organisations. Profit makers certainly need focus for firms to generate revenue and ultimately survive. Regardless, treating cost centre employees differently breeds animosity. Their support is needed to ensure profit areas thrive.

Come And Get It

This differing treatment also applies to individual gains. A deviation from the pattern of desks is immediately noticeable. Fascination with recently installed sit stand desks is a prime example. Once two were installed, we received a large number of enquiries. It is very much the shiny new toy that everyone craves, yet understandably so.

Incremental improvements are a great way to test the waters and crowdsource ideas to improve your environment. The media is filled with stories of large technology firms providing numerous perks to motivate employees. However, they have an ulterior motive to keep you in the office.

Employees want to see the dazzling night skyline from home, not the office

People do want to work, but generally they also want to go home at a reasonable hour. Well… most of us anyway! It’s about supporting programmers work while they are present in the office. Even the proposal of a floor cat and table football machine on our board were put forward to address issues of pests and productivity. Regular breaks are important after all!

Same Size Feet

It is becoming exceptionally clear that incremental improvements work for a while, but will only go so far. Bigger budget items take longer to propagate through the environment. Generally, suggestions put forward for perks have been sensible additions proposed to retain your best people and address current problems.

Given the chance, engineers generally put forward constructive improvement suggestions. It’s not all about candy floss!

I’m not expecting any requests for Candy Floss Friday’s anytime soon. Cotton candy for my American friends. With all colleagues being created equal, our incremental improvements will soon need to scale to reach the masses. Given time, I hope everyone will be playing desk goes up, desk goes down Simpsons style!

Thanks for reading! Also check out my piece on the effects of developer perks on non-occupying stakeholders.

A Design For Life

Pursuing User Experience Agility

To be, or not to be, that is the question. Hamlet was contemplating death here. In Agile circles we don’t cover quite as morbid a topic. However, through continuous integration we do broach the subject of whether tools and techniques should live, evolve or die within our Agile process.

Technique X is not Agile. I hear engineers and leads alike utter this statement a lot. For some artefacts such as long, rambling requirements documentation this aversion makes perfect sense. At this point I imagine a choir of voices chanting in union the principle working software over comprehensive documentation.

Reluctance by our software engineers to generate wireframes and mock ups is driven by their perceptions of agility

I never thought I would see the day where x ≠ wireframes would be solution to this equation. Even more frightening, that I would hear this feedback second-hand from a client. Here I outline my thoughts on the importance of wireframes and mock-ups within Agile development practices, and ponder their place in Agile development processes.

No Education

Firstly, an education on what wireframes and mock-ups are is required. Clients and developers alike often confuse the terms. Even I myself use the terms interchangeably. On reflection, the confusion in our team is probably driven by my conflicting usage. Now is the time to make up for past sins.

A wireframe is a low fidelity outline of a screen and the data groupings it comprises. Designers may also include descriptions of intended interactions. Meanwhile, a mock-up is a mid-level static representation of the product appearance that users cannot interact with. Think initial sketch versus polished image. Prototypes are high fidelity representation of the appearance and interactions the final product will provide with which clients can engage.

There are many resources that can outline the differences between wireframes, mock-ups and prototypes, along with the tools that can be used to create them. This article by Marcin Treder is one of many.

Mind Eraser

I am by no means a designer. I have developed an appreciation for sketching screens through years of UI development. Far from having the top tools to create wireframes, I normally start by sketching option on a whiteboard and emailing the pictures. It takes a level of empathy for me to understand the motivations for considering these artifacts anti-agile.

Rather than immediately criticise, lets consider what experiences have driven thoughts that wireframes are “not agile”

Walking in another pair of shoes, I can see why designing a full screen could be construed as a Big Bang effort. Not only do the individual components need to be defined, but transitions and affordances must also be outlined. This might be construed as following a plan designed upfront, when adapting is critical. Others might argue it serves as documentation that is being developed in place of working software. To justify their place in our development cycle, we need to break these misconceptions.

Little Changes

Another fallacy driving these opinions is that wireframes are difficult to change. Linked to the all or nothing conjecture, it is perceived that swapping parts of the screen cannot be easily done. In this instance, evaluating numerous chart options with clients seemed challenging as it was believed they could not be swapped out. Therefore a decision was made without engaging users.

You’ll often find me with headphones on dancing in front of a whiteboard sketching my ideas out, much to the annoyance of my colleagues

In reality, I often change mine through the swipe of a whiteboard eraser. Recently in the midst of an ideation brainstorm, I was able to create three different screen designs with the help of my trusty whiteboard. Carly’s corner whiteboard is becoming an ongoing joke as a result. These designs can be reviewed with clients and programmers alike. Designs can evolve iteratively through this method. Engineers just need to realise that rough scribbles are a valid design tool.

Draw the Line

There is still work to do to get buy in from our developers that sketches are a critical element in their client engagement. Looking forward, I envisage creation of mock up and prototypes without debate. They can help address some of our ongoing challenges in enforcing consistent design and common styling. Mock-up software such as Sketch has powerful capabilities to generate style sheets from designs. Automating our centralised style sheet changes would greatly reduce our current review overhead. With developers rushing to write code, it is important to highlight the output mock-ups can have in making time to develop more streamlined.

One day, once wireframes are established, mock ups could help us further engage with our clients

The effort required for collaborating over wireframes can make delivery of a feature in a single iteration exceptionally challenging. I’ve heard recent reflections from others in their adoption of UX within Agile development that will help. Generating designs ahead of time will ensure they continually feed into our development cycle. Regardless, these are a powerful tool for fostering user participation in our development practices. With client collaboration driving our agility, any mechanism that supports this engagement should be adopted.

Thanks for reading!

Cherry Blossom Girl

Part Four of My Japanese Adventure

I’ve never been the best at maintaining that elusive work-life balance. I certainly have enjoyed blogging about my recent Agile and UX experiences over the past few months. Nevertheless, I’m only human after all. Therefore once in a while I need to take a break.

I’m currently embarking on my dream holiday of travelling through Japan with my panorama pro husband. I have loved sharing our experiences thus far. Furthermore, it allows me to keep my promise to numerous friends and colleagues to share some of the hoard of photographs I’ve taken along the way. Following on from our exploits in Hiroshima and Miyajima, check out our adventures in Kyoto and Osaka.

Day 9

Today we say goodbye to the beautiful island of Miyajima. Wandering through the quiet morning streets before the crowds arrive is exceptionally peaceful. It gives us a great last opportunity to savour the sites of the shrines and Tori gate before boarding the ferry back towards the mainland.

Another day, another Shinkansen. This time we are off to Kyoto. With the average speed of 300km/h we make it from Hiroshima to Kyoto in no time at all. The efficiency and comfort of these trains certainly doesn’t get boring when you are used to the fun of London rail delays caused by leaves and sunshine.

Welcome to the bustling city of Kyoto! The former Imperial capital of Japan. We arrive at the station famished and find a tiny place serving udon noodles. It was exactly what we needed. I also received much thanks for finding a lost phone. Gratitude does indeed translate across language barriers.

Wandering around the station we find the Miyako no Taki Water Sign. Yes, this is far from a tourist site worth mentioning. Regardless this gave us a reminder of the Canary Wharf installation we regularly see back home. This one is far more sophisticated projecting shapes rather than words, but was still a nice sight to see.

Our first stop is Nijo Castle, completed in 1626. Finding the moat is indeed easy, but the entrance itself not so much. Regardless, once you enter there are many amazing sites to see. We enjoyed savouring the palace and gardens. The palace and rooms are exceptionally ornate.

Following checking into our hotel, we ventured out into downtown Kyoto. The central region has a surprising number of western style restaurants and bars. These are separated by numerous karaoke bars. Not that I’m inclined to venture into those and inflict my voice on the population of Kyoto!

Instead we opted for a more chilled out evening in a back street bar. After a day of travelling and sightseeing it was great to chill with wine and grilled beef tongue.

What has became apparent over the course of the day is there are a lot more tourists in Kyoto who are more likely to drum up a random conversation. The chatting Singaporean living in Sheffield striking up a conversation on politics would definitely be less likely in Tokyo.

Day 10

On our first full day in Kyoto, we are off to Arashiyama to explore the legendary bamboo forest. Even with the crowds of tourists, it is an absolutely stunning place to explore. There are indeed ruminants of these hoards left behind, including carvings in the bamboo. Nevertheless, staring up among the trees and admiring the various shrines dotted around the forest made for an enlightening morning.

Navigating the various transport lines and buses takes us across the city to Kinkakuji. This stunning golden Zen temple is the former retirement villa of the shogun. Us and the other throngs of tourists were fortunate enough to stroll around the temple and gardens on a sunny autumn day when the sun reflects off the golden floors perfectly.

From golden yellow we move onto vibrant red and visit the famous red gates at Mount Inari. Fushimi Inari Taisha is the head Shinto shrine of the god Inari. This is apparent from the foxes dotted around the various ornate shines present across the mountain. Wandering amongst the gates gazing at the setting sun was definitely a good end to the afternoon.

The evening brings a new adventure with us heading back into the city centre to explore Gion. The historical Geisha district is a bustle of bars and restaurants today. Exploring the bright lights we did catch glimpse of a geisha while teaching a kindly Japanese man English. You can’t make these things up!

Day 11

Today is wildcard day, with a surprise trip to Osaka. We can’t plan everything after all! Being Scots and Whisky fans, our first stop has to be the Suntory Yamazaki distillery. This is the first Whisky distillery built in Japan.

Tours are available, but unfortunately were booked out before we left for Japan. Nevertheless, the museum is is definitely worth a visit to discover the history of this amazing distillery. Downstairs is the Whisky Library, which shows the numerous different malts these use to blend their whisky. A cheeky tasting flight in the bar is definitely a must as well!

Next we head onwards to downtown Osaka. Our first stop is Osaka Castle, a key site in Japan. Located in the middle of a large park, we enjoyed strolling by the river gazing at the castle and eating pastries. We found this more our style than the small train that runs through the park.

Next we head to the Tsuyu-no-Tenjinja shrine. Historically this has been the guardian shrine of the Umeda district of Osaka. However, it also highlights the story of forbidden lovers Ohatsu and Tokubei. These characters feature in a Japanese play apparently based on a similar double suicide of two lovers. Unlike the bustle we have seen in Kyoto over the past few days, this shrine is pleasantly silent and reflective.

The quiet of the shrine is a stark contrast to our next stop, the bustling Shimsaibashi shopping district. The arcade is absolutely packed with people. Imagine the crowds of Oxford Street multiplied by a factor of 100. The shops house a mix of Japanese and Western brands. It was this moment where we finally find those elusive Matcha Kit Kats!

The Shimsaibashi arcade intersects with Dotombori, the main restaurant area. The intersection is also packed with people. Upon crossing the river you see masses of people and lights. Many of the adverts have sound so you have multiple messages mashing together in your ears as you cross.

This seemed like a good stop for some food. One of the items we’ve been itching to try in Osaka is Takoyaki. Osaka is the city of food after all! These squid balls are exceptionally tasty indeed. Even if ours didn’t have any tentacles sticking out!

Travelling back to Kyoto was a fun experience. The Keizen railway has different train types that stop at different station. Thankfully the limited express did stop at the right station for us, and in record time too!

Our final moment of Kyoto consisted of enjoying cocktails in a local bar with travellers from all over the world. Being able to sample a few Japanese gins, including the Ki No Bi recommended to us back in Tokyo was definitely a good end to our stay before heading home. Somehow the trip has come full circle.

All good things must come to an end unfortunately. We have absolutely loved experiencing the sites and lights of Japan. Hopefully you have enjoyed reading about our journey too.

Thanks for reading!

Island Girl

Part Three of My Japanese Adventure

Those who know me are fully aware that I’m not the best at maintaining a good work life balance. I have nurtured a love of writing about my Agile and UX experiences over the past few months. It has never felt like work. Yet some would argue I have used my spare time to extend my work hours. Nevertheless, even the most industrious of individuals needs the odd few days off.

I’m currently embarking on my dream vacation of travelling through Japan with my exceptionally patient husband. With strong interest from friends and family back home, I have been regaling my adventures through my blog. Following our exploiting in Tokyo, Kawaguchi and Hakone, we are experiencing a change of scene exploring Hiroshima and Miyajima.

Day 6

Today we are leaving the hot spring resort of Hakone to travel to Hiroshima. With no seat reservations we did wonder if we would be able to get on the train. I am haunted by a rather uncomfortable bank holiday train to Glasgow standing in a vestibule all the way to Carlisle.

Using the Shinkansen it could not have been easier. With one change and an operating speed of 320km/h, the 729km journey took just over 4 hours. Leg room is never a problem, so it was a far more comfortable experience too.

By mid-afternoon we are in downtown Hiroshima. The immediate notion we have is the height of the buildings. While not as tall as the towering skyscrapers of Tokyo, they certainly put Glasgow to shame. The daytime views are stunning. It was easy to gaze out from our hotel and see the buildings nestled by the surrounding forests and mountains.

Regardless, this pales in comparison to the night view. Being the hubby’s birthday we enjoyed steak cooked on a teppan grill overlooking the bright lights of the city. That and a couple of cocktails made for a chilled evening following a long day of travelling.

Day 7

To ensure adequate fuelling for our exploration through Hiroshima, we had to have a substantial breakfast. The majority of our hotels so far have offered a mix of Japanese and Western style food. This morning we decided to be adventurous and try out a traditional Japanese breakfast.

Although not my image, we were presented something similar to the above including Japanese tea. I’m proud to say I enjoyed almost all the elements. Eggs have never been my thing, so did give the rolled eggs a miss. Mr Richmond wasn’t a great fan of some of the more sour pickles either. But definitely would have most of the elements again, especially the fish and miso, which have been an ongoing holiday staple for us.

One of the main transport mechanisms in Hiroshima is the Streetcar network. Riding on these cars brought back fond memories of navigating the San Francisco Trolleycars. These proved invaluable for reaching all the sites we aspired to visit.

Our first stop of the morning is to Hiroshima Peace Park. This gorgeous green space and its many monuments are dedicated to the memory of the dropping of the atomic bomb during WWII. Upon entering the park, you are faced with a stark reminder of the impact: the Atomic Bomb Dome. The former Hiroshima Prefectural Industrial Promotion Hall lay within the epicentre of the blast.

On this glorious day it was pleasant to walk through the park. There are numerous landmarks dedicated to the eradication of nuclear weapons throughout the park. In addition to the eternal flame, the Children’s Monument Bell and Phoenix Tree are definitely worth admiring. I did see a rather amusing moment of a child enthusiastically ringing the bell which made me smile.

I was indeed surprised at how respectful the majority of tourists were. Unlike the majority of other sites we have visited, pushing to read signs and take photos is replaced by polite and quiet reflection.

Onto happier notes, we went off in search of Hiroshima Castle. The original castle was built in the 1590’s, and reconstructed following its destruction by the Atomic Bomb. Stepping over the moat and visiting the carp, shrines and former home of the daimyo in the midday sun was immensely enjoyable. Especially for Mr Richmond who managed to capture an image of a ninja sneaking behind me, which is available on request.

All that walking does makes for hungry travellers. Following recommendations at the hotel, we were keen to try the local delicacy of Okonomiyaki. For those who are unfamiliar, this is a savoury pancake loaded with noddles, vegetables and meat toppings cooked on a teppan grill. There are many restaurants dedicated to making it across the city.

Okonomimura has around 25 different vendors producing their own variations. This tower of food is definitely a good place to start! This was one of our favourite dishes of the trip so far. While I kept things a bit more traditional and enjoyed the scallops version, Mr Richmond went all out for cheese and rice cake. Both were exceptionally tasty, so do give it a try if you ever have the opportunity.

Following our enjoyment of the Hamarikyu Gardens back in Tokyo, it seemed only fitting that we explore another Japanese garden in Hiroshima. The Shukkei-en Gardens are a tranquil escape from the bustle of downtown Hiroshima. Our latter portion of the afternoon was spent strolling through the peaceful gardens admiring the various shrines and bridges across the route. Every nook and cranny of this garden has a site to see. Look out for the mini bamboo and tea gardens, which were highlights of ours. I also suggest checking out the plum orchard if you have time.

Being a Saturday night, we can’t just stay in the hotel. This evening we chose to explore the Naka region, which is the lively entertainment district of Hiroshima. Unsurprisingly it has an array of shops, bars and restaurants lit up by neon signs in the evening.

The perfect end to our day was trying the Hiroshima delicacy of baked oysters, washed down with Shochu. Japanese food is very seasonal, son we were fortunate being here in the autumn that they were starting to come into season. This seemed like a good compromise over the milt that Mr Richmond was reluctant to try!

Day 8

No journey to this region would be complete without a trip to Miyajima island. It is a small island off the course of Hiroshima, where people are forbidden to give birth or die on the island. Spoiler alert! Neither of these happened to us.

The ferry from the mainland to the island itself is only around 10 minutes in duration. With such a short window, it is amusing to watch tourists attempting to determine the best side to capture the famous Tori gate. Although we did get a few photographs on the ferry, the best shots are yet to come!

Our research before arriving told us much about the numerous shrines, shops, ryokans and other attractions present on the island. Nevertheless, surprises are indeed waiting to be found. Our first of the day was encountering the Sika deer that roam the island. These creatures are exceptionally friendly and docile when encountered off the beaten track. Do be wary that, like the seagulls of Largs, you may find yourself wrestling with them for your lunch if they catch a whiff of it!

There are plenty of shines and temples on the less well travelled track that are worth exploring on this picturesque little island. The less visited Tokujuji temple gave a pleasant moment of peace before rejoining the throngs of tourists in the main shopping arcade.

We are drawn to the main shopping streets by the sound of drum beats. Amongst the myriad of souvenir shops and restaurants, natives and willing tourist volunteers were bashing dough with hammers in preparation to make local bread.

Watching all this dough beating was indeed hungry work, so at this point we decided to sample some local delicacies. Since Mr Richmond had missed out on oysters the night before, he elected to try the fried variety. Meanwhile I branched out to try anago, or conger eel. Although jellied eel is a delicacy in London, it’s not really the most appetising sounding dish. This eel however, was fresh and delicious!

Over the course of the afternoon we visited the more popular sites of the island. It definitely showed as we navigated our way between the throngs or tourists and the friendly Sika. The Itsukushima Shrine and corresponding floating Tori gate are world renowned. Judging by the large volumes visiting this proportion of the island it certainly seems to be the case. Yet, when gazing upon their vivid orange colour I do understand the appeal. Thankfully there are numerous other attractions such as the Pagodas and the aquarium to provide variation.

Walking around shrines is thirsty work. Before settling in for dinner at our Ryokan, it was time to relax with a beer or two. By chance we happened across the Miyajima Brewery. It may be unbelievable to consider we had no knowledge of this brewery prior to visiting, but this was indeed our second surprise of the day! They have the small seating for takeout beer as well as the restaurant and bar where you can gaze out at the dusk skyline enjoying a beer flight.

Our final stop for the day is to our Ryokan to enjoy some Japanese hospitality. After settling into our Japanese style room to savour green tea and Momiji Manjyu, we enjoy a meal of local delicacies in our room including oysters and sea urchins!

The perfect lazy end to a busy day on the island is to soak in the Onsen. Following that we are on to Kyoto and Osaka!

Thanks for following my adventure thus far!