Carly Richmond

Lady of the Lake

Part Two of My Japanese Adventure

Maintaining that elusive work-life balance has never been my strong point. I do enjoy writing about my Agile and UX experiences. It has never felt like work. However, even a workaholic such as myself needs to occasionally call time out.

I’m currently embarking on my dream vacation of travelling through Japan with my now slightly older husband. Given it’s been all I’ve talked to friends and colleagues about since I booked it back in March, it seemed only fair that I share my experiences in blog form. Following our trail through the neon lights of Tokyo, we continue out travels through Kawaguchi and Hakone.

Day 4

A new day, a new means of transportation. The small town of Kawaguchiko is the gateway to Lake Kawaguchi. Stumbling into the daylight following a two hour bus journey, food seemed an appropriate first stop.

One of the key delicacies from this area is Houtou. These thick Japanese noodles are cooked in a cast iron pot with miso broth, sweet potato and root vegetables. It tastes wonderful, but that is a hot bowl! Even I, known for eating boiling hot food initially struggled with this one. Nevertheless, sitting shoeless on the tatami matts waiting for the broth to cool made for an enjoyable and authentic experience.

After sourcing sustenance, we explored the town of Kawaguchiko and the lake itself. The ropeway serves as a great mechanism to reach the Mount Fuji viewing platform. If you can resist the delectable smells of the cookie shop, it’s worth a trip to the viewing platform. Today wasn’t particularly clear for us, but Mount Fuji was definitely an extraordinary site to see.

Lake Kawaguchi hosts numerous activities on its shores from museums to cafes. All outlets are geared to enjoying the lake. I can imagine the shoreline teaming with people in the summer. In October it is beautiful, but decidedly quiet. Our highlights were walking around the lake capturing the shrines and stillness of the water. That and the paddle boat ducks of course!

Wandering back through the town to the bus station, there are definitely other sites to see. The Ide Sake Brewery and the nearby Sake shops are definitely worth a look. If you visit earlier in the year around brewing season, embarking on a tour to see the brewing process would certainly be a sight to see.

From here it was back on the bus to enjoy the last spectacular sites of Tokyo. Check these out in our day four Tokyo highlights!

Day 5

Today we leave Tokyo to continue our journey west. Hakone is a short journey from Tokyo. This is our first opportunity to ride the Shinkansen! For this unfamiliar, this is the famous bullet train that can reach speeds of up to 320km/h. Definitely puts the speed of my morning commuter train in London to shame!

Odawara serves as one of the main entry points to Hakone. A short walk from the station is Odawara castle, built during the Sengoku civil war. Similar in style to the Tokyo Imperial Palace, it was a nice deviation on our journey.

Before we know it we are in Hakone. This area is know for its mountains and hot springs. One further reputation unbeknownst to us before we arrived, was the sheer number of different transport mechanisms used to get around. It makes the London commute of switching trains seem far more straightforward.

Our first stage was utilising the Hakone Tozan railway to get to Gora. This is definitely the first time I’ve had a train change direction several times over the course of the journey.

Following a post-stop ramen break, we take the cable car to Sounzan.

Then several ropeway connections to Tokendai-ko. From the cars you can get spectacular views of Mount Fuji, the hot springs, the vast forests and Lake Ashi.

The Lake Ashi pirate ship, yes I did say pirate ship mateys, gives stunning views over the lake. This was the perfect opportunity to capture some of the red gates floating in the water.

Our final transportation of the day was the bus to Hakone-Yumoto station. Following a brief stroll through the town, and saying hi to Darth, we arrived at our hotel for the night. With this being the most varied journeys I’ve taken to date, I’m going to at least try and complain slightly less about the London commuter parody for at the the first couple of days after we return!

Tonight we are staying in a Ryokan, or Japanese inn. Often they have both traditional Japanese and Western style rooms. Thankfully, we got the former. The room itself is initially laid out for sitting, and will be converted to sleeping quarters later in the evening. We also had an outside bath area backing onto the river, which was pretty peaceful.

Dinner is included with your stay. The set menu covered various different delicacies, including conger eel and rice boiled by candle in a cast iron lantern. Depending on guest preference, some choose to eat in their Yukata and Haori. The key difference between a Yukata and Kimono is the fabric is it made from. Don’t worry, we didn’t partake until later! A nice addition in this case was the extra dessert offered for my husband’s birthday. A complete and pleasant surprise.

Ryokans commonly have communal and private Onsens, or baths. It is traditional for all guests to bathe in the Onsen. Culturally this is a pretty unique phenomenon. The closest equivalent for us Brits is booking in for an overnight spa visit. Relaxing in the warm water was a perfect way to recuperate after walking around in the Tokyo bustle. This is the point we put on our Yukatas and settled onto our foutons for the night. Photo evidence was obtained, but I think I’ll leave those for me.

Thanks for reading! The next stops are Hiroshima and Miyajima.

Woman From Tokyo

Part One 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. Similar to recent sitcoms, I too need a mid-season break.

I’m currently embarking on my dream holiday of travelling through Japan with my patient husband who has a sense of direction. It would be unfortunate if I couldn’t share our experiences along the way. Furthermore, it ensures I keep my promise to numerous friends and colleagues to share some of the prodigious photos I’ve taken over the past few days. This piece covers our exploits in Japan’s capital Tokyo.

Day 1

Having arrived at 7am local time with next to no sleep, myself and the hubby have been doing some initial exploring to ensure we stay awake until our 3pm check-in time. What better way than to explore Tsukiji market. Everyone is exceptionally friendly and welcoming, including this guy!

Although the main market closed a mere one day prior to our arrival, the outer stalls are still selling a variety of delectable treats. I definitely recommend trying out the various fish on a stick, or yakitori. I wasn’t brave enough to try eel livers or crab brains in my jet lagged state, but they did look pretty yummy. The sashimi also looks exceptionally enticing.

Dessert proved to be interesting. My husband’s initial attempt to buy ice cream turned a bit wrong when he came back with a Japanese omelet. I’m not complaining. It meant I could try out matcha mochi with strawberry, which puts UK mochi to shame!

Following check-in and a quick power nap, we’re off to seek ramen. It’s only until you actually try the real thing that you realised what we enjoy as ramen in the UK is not the same. It’s always pork, and is absolutely delicious. Thankfully when ordering food either from cryptic vending machines or vendors, everyone has been exceptionally friendly and helpful. Any attempts to speak Japanese have always been very well received!

Today has mainly been about food and trying to acclimatise to the new time zone. However, in the evening we still found time to explore Shimbashi, housing an array of shops, bars and restaurants.

Among the lights of this amazing city, we have managed to find a steam engine and a Wacky Wailing Inflatable Arm Flailing Tube man. When your Wifi hotspot has died on the first day and you are totally lost, it’s the little things that can make you smile.

Day 2

As I’m writing this I definitely feel like I have walked over 26,000 steps today. On our first slightly less jet lagged day we braved the bamboozling transport system to explore the city. Our first stop this morning was the Meiji shrine. Following the lights of Shimbashi, finding a more reflective spot was appreciated. With the leaves starting to turn, you could spot flecks of autumnal red in the trees starting to appear.

Despite being a national holiday, the shrine was reasonably peaceful. We wandered through the gates, and caught sight of a wedding ceremony at the shrine. At Shinto shrines across Japan, offerings of Sake by distilleries are common place. Regardless, Meiji is the only shrine in Japan where are also wine offerings from French wineries. Of course I had to capture the latter!

Next was a tale of two shopping areas. Walking down Takeshita street in Harajuku on a bank holiday makes Oxford Street seem eerily quiet. The street was filled with youngsters and tons of shops. Definitely far more crepes shops than I expected!

Not that Ameya-Yokocho market is any quieter. This bargain haven reminds me of The Barras market in Glasgow. Just like The Barras, it is filled with an array of stalls selling wares from fish to metal band t-shirts.

After lunch we are off to the Senso-ji Buddhist temple. This was where the national holiday became apparent. In addition to the sea of people eagerly taking selfies in Kimonos, Japanese flags waved proudly from the souvenir stalls.

From underground we moved onto the river to cruise down the Sumida river. With the boat ducking under the many colourful bridges on route, we spotted some additional sites including the Skygarden and the Asahi brewery headquarters, which looks awfully like a pint of beer.

Our final stop for the day restored some tranquility following the bustle of the markets with a trip to Hamarikyu Gardens. It is surreal that this natural haven is present in such a big city. The Tokyo Tower in the background serves as an ever present reminder of where you are. Walking around the pristine gardens and enjoying Matcha was a good reflection point before heading out in the evening.

No day in Japan would be complete without an amusing anecdote. Today’s tidbit comes from our evening in Ginza, searching for an open restaurant on a national holiday. My excessive over reliance on Google Maps, and lack of direction certainly made for an interesting evening. Especially when we gave up and ended up in a Belgian beer bar a couple of months after going to Bruges. All I can say is that I finally tried Coconut beer, and it was awesome!

Day 3

Now that we have our bearings, it’s time to venture outside the usual tourist haunts. Well… sort of. Following a recommendation, our first stop of the morning was Odaiba. Since capturing the best shots of the NYC skyline from New Jersey as a graduate, I’ve always thought the best city views come from afar. Odaiba did not disappoint.

During the day, Tokyo looks amazing from here. However, the above bridge is called the Rainbow Bridge for a very good reason. If you come back in the evening, this pristine white bridge is lit up in a series of colours that I imagine would entice the imagination. Definitely worth considering if you have the time.

Views aside, there was a secondary motive. Odabia also has a replica Statue of Liberty, which taking selfies in front of is a massive tourist hot spot. The only area exhibiting this level of pop culture pilgrimage that I’ve seen first hand is the zebra crossing outside Abby Wood studios in London. Nevertheless, it does mean I’ve now seen three lady liberties including those in Paris and New York. It does bring back fond memories of graduate training in NYC. More akin to the cheese of Coney Island Pier or Blackpool Pleasure Beach, but hey we’re on holiday!

Next we’re off to central Tokyo to check out the Imperial Palace. I did skip the gardens. Nevertheless, wandering around snapping the gates and statues was a lot of fun.

The proximity of the palace to Tokyo station means it would be rude not to visit. The red brick exterior hides to deceptive maze of tunnels that commuters migrate through. For us tourists, it also houses the aptly named Ramen Street and Character Street. Visiting the former was for me. Strolling down the latter was for the nieces and nephews back home. When you see the biggest Pikachu you’ve ever seen, you just have to take a shot for the little ones!

Next, we’re off to Udeon. There is a nice balance between greenery, museums and shrines that are worth exploring. If you are a museum buff, it would be exceptionally easy to spend a full day here. We spent a couple of hours investigating the park, with our key highlights including the Tsongu shrine and the giant whale outside the Natural Sciences museum.

This evening it was back to Ginza on a non-bank holiday to sample some of the restaurants and bars. I’ll be honest, I did fall in love with a cocktail bar. Doesn’t matter what city I’m in, if I can find a small quiet spot where they make a mean Old Fashioned I’m happy to perch. However, it has thrown a spanner in the works as the Martinez made with Dutch Jenvever was exquisite. We received a great gin recommendation that I intend to find when we visit Kyoto.

Day 4

Today we were up bright and early travelling to Lake Kawaguchi to bask in the glory of Mount Fuji. Full details on our expedition through Lake Kawaguchi and Hakone will be documented in my upcoming blog.

Arriving back late to Tokyo, we needed to make the best of our last night in this amazing city. Like a moth to a flame, we were drawn to Shibuya Junction. This point for me represents the bustle and bright lights of Tokyo. In addition to capturing a panorama of the new signs, it was only fair that we amble across the junction and back. I’m proud to say our years of living in London have taught us the importance of crowd management. We didn’t bump into a single person!

Following the bright lights, we spent the remainder of the evening exploring Shinjuku. Above ground are towering buildings and flashing advertisements everywhere. Below ground is a behemoth of underground shopping malls that are easy to lose yourself in.

Regardless of this challenge, we reached Golden Gai. For those unfamiliar, this is a maze of tiny bars popular with tourists and expats. This did reaffirm my notion that shag carpets on walls is definitely out. Nevertheless, the journey through the alleys for food and libations was a satisfying end to a frantically fun few days.

Thanks for reading! Do read on to find out all about my adventures in the lakes of Kawaguchi and Hakone!

Pushed to The Limit

The Importance of In Progress Limits in Software Development

Life is full of limits. Whether they be imposed by societal pressures; government legislation; or even a byproduct of unfortunate events; they are indeed present. Breaking the smaller rules is exhilarating. However, generally we abide, even with those that seem less sensible.

Restraints also apply on the amount of work we can undertake. For humans and computers alike, multitasking is a fallacy. Rather than exhibiting true parallelism, we context switch between operations. If we believe that we are truly good at multitasking, it is more the case that we think our context switching overhead is minimal. In reality, it contributes to wider productivity issues.

Computers can multitask with multiple cores, but humans only have one brain

Recent events have highlighted the challenges multitasking imposes on software delivery. Here I reflect on programmer parallel processing, and the importance of establishing work in progress thresholds.

Working on a Dream

Before delving into my personal experiences, it is important to reflect on the origins of Work In Progress. WIP is a fundamental principle of Kanban. The aim of the game is to match the velocity of developers to establish a consistent effort cadence.

Adoption of a constant pace allows us to develop software in a dependable manner. Our clients think it’s great that they have a regular release cycle. Engineers are happy that their work rate is constant. Previously we had significant up rates as they scrambled to finalise features for the next release.

Despite experiencing these established benefits, we have seen bad habits emerge. Management pressure occasionally results in programmers working on both new enhancements and bug fixes concurrently. I find myself asking, is this the right approach?

Parallel Minds

Context switching may feel like we’re being more productive. We do have several engineers that will commonly work on two tasks at once. I understand the appeal. Humans do like variation in their tasks. Working on several items provides a level of satisfaction. Nevertheless, it has side effects.

Engineers working on concurrent tasks lead us to believe limits were required to prevent delivery delays

Lack of dedicated time may affect the quality of the final implementation. Splitting your attention will also split your attention to the details. Programmers may miss edge cases that would have otherwise been detected.

For me as a lead, tracking what items are going to be available for a given release becomes an impossible feat. Keeping clients abridged of upcoming features is challenging enough. Ideally, developers would focus on a subset of stories and complete the features at a regular pace. With multitasking, we run the danger of no features being available if an unfortunate events arise. Even in an opportunistic world, individual stories will take longer to ship.

Take it to The Limit

It was becoming clear that key individuals were task thrashing. Subtasks were not being distributed among the team. This lack of distribution is partly a side effect of engineers wanting to own their own feature. It’s one of the key reasons we have struggled with feature toggle aversion in the past. Senior developers can fall into the trap of completing common tasks because they can complete it more rapidly than less enlightened colleagues.

Brent is a bottleneck in The Phoenix Project by Gene Kim et al.. For those unfamiliar, Brent is an experienced engineer that is found to be a process bottleneck due to his superior knowledge. I recently faced the terrifying realisation that I have more than one Brent in my team.

With reliability of delivery starting to slip, action was needed to reduce the number of concurrent items on which individuals were working. At this point, it was imperative to introduce limits. Ideally, I would have preferred no more than one task assigned to any given developer at any one time. As our tools prevented this, I resorted to a simple task count on the development state. The team had concerns of such a low ceiling impacting release management items. So a compromise of two points was reached, and evaluated over several weeks.

Invisible Limits

Applying an upper bound to the development state on our board initially proved effective. The first week saw programmers progress work items through the states without breaching. Regardless, all good things must come to an end. Far from being a warning, after a while it became an everyday event. It seemed like for a significant period of time we were always infringing on our limit.

Like speed on a highway, development teams need to establish limits on work in progress

Originally, I feared we were becoming desensitised to the red. My inaugural mindset of stopping developers pushing the boundary needed to evolve. It’s more important that engineers adopt the habit of clearing items when they do infringe, rather than continue to take on work items.

The squad must also become comfortable with reassessing any established workflow restrictions. Like any part of our process, experimenting with thresholds will allow the team to improve their development practices. Just like people, every collective has their limits.

Thanks for reading!

Coffee Homeground

Revisiting Java Code Reviews

Coffee. Chocolate. A good ol’ cup of tea. Food or otherwise, we all have those home comforts that instill a feeling of coziness. The little things that give you a warm fuzzy feeling when curled up on the couch in times of joy or strife. Technologists commonly exhibit similar attachments to programming languages and frameworks.

Programmers develop a technical comfort zone for languages and frameworks that are as inviting as a cup of tea

Be it Java, Haskell or Typescript, nothing gives you a higher feeling of elation than being in the coding zone using your comfort blanket language. Coupled with your favourite IDE, solving problems in the comfort zone is immensely gratifying.

With my recent role change I’ve been forced out of my Typescript comfort zone. Moving to a product focused role has meant I’ve had to dust off my Java skills and review team changes. With me completing my last from scratch feature 7 years ago, it has proven difficult. This week I reflect on the challenges of reviewing code in unfamiliar languages, and how my experiences can help you re-adjust.

Wake Up And Smell the Coffee

Technology evolves rapidly. Programming languages and frameworks are no exception. One such example that has been close to my heart over the last 3 years is the evolution of Angular. From Angular JS to the upcoming Angular 7, I have used the majority of these versions. Each contained a host of new features. The JS rewrite in particular resulted in a significant learning undertaking for developers.

Lack of experience with new language features leaves you playing catch up. One of the major features used extensively by our team that I bypassed is Java streams. This enhancement introduced in Java 8 allows for adoption of a functional style. I can safely say this has been one of the constructs that I’ve had to invest considerable time investigating.

Drawing from my prior experiences of JavaScript frameworks has helped me learn Java streams

Another strategy that can help is drawing parallels with technologies recently used within your comfort zone stack. Within the Web domain, similarities to both Lodash and RxJS Observable pipes have helped me adapt to Java streams. Your experiences with all languages will help you grow and adapt to new technology more quickly.

Clouds In My Coffee

Coding involves an element of pattern matching. Think back to an internship, or your first role. At that time, you were most likely more humble. You were comfortable acknowledging that you didn’t know everything. If your experiences were anything like mine, there was a lot of online searching and combing of forums such as Stack Overflow to find your desired answers. Another strategy to acclimatise to unknown code bases is to replicate any common patterns that you detect. The latter is one I’ve seen our interns adopt more recently.

In different languages, there’s a pattern, there’s a pattern, there’s a pattern, there’s a pattern…

Heuristics such as Uncle Bob’s Clean Code guidelines and Martin Fowler and Kent Beck’s Code Smells translate across technologies. When adapting to repositories written in unfamiliar programming languages, not all patterns from your home code base will translate. File structure is one obvious example. Our Java code bases follows the Gradle structure. Meanwhile our UIs adopt a flat file system as per the Angular Style Guide. It is worth identifying the build frameworks used to develop an intuition on where code will live.

Class design patterns also differ. With years of Web and Desktop UI experience, structuring features using Model View Controller, or a related variant, is ingrained. I’ve had to acclimatise to the common REST service endpoint class composed of a dedicated response handler and DAO. Your friendly neighbourhood IDE can help greatly, especially the search and find definition functions.

There Might Be Coffee

Contemplating possible performance issues in unfamiliar languages is another issues I’ve faced. Identifying potential bottlenecks and concurrently issues is challenging at the best of times. I’ve always found that programmers struggle to write and understand concurrent code. It has certainly been a cause of some recent production issues. Throw in confusion regarding concurrent collections and locking mechanisms and these issues can be difficult to prevent.

Identifying bottlenecks and other performance issues is not easy in unfamiliar technologies

Without knowledge of language specific best practices, you’ll struggle to reason about performance outside general algorithmic complexity. Utilising various resources can assist you in your learning quest. Tools such as profilers can help you diagnose elusive bottlenecks. Also, seek out technical mentors to work through your ideas and concerns. Ideally have more than one to obtain differing opinions and to ensure help remains if your rock star mentor leaves. Reading can expose industry best practices. For Java specifically, I’ve added Java Concurrency in Practice by Brian Goetz et al to my reading list to continue my journey of enlightenment.

One More Cup of Coffee

Delving outside our technical comfort zones can be daunting. It is assumed that a technical lead will be able to lead across the stack. Some patterns do translate across the technical expanse. But others do not. Regardless, it is important to ensure unsuitable constructs and designs are not translated into the new technology. Such mistakes will affect readability, maintainability and system performance.

With our ongoing push for our technologists to become full stack developers, my recent experiences has proved enlightening. I’ve been able to empathise more with the key challenges our Java developers are facing as they learn Web technologies. It has given me more of an appreciation for the support managers need to provide programmers.

I hope my experiences allow me to lead by example. I’ve always wanted to encourage engineers to embrace diving into unfamiliar technologies. Only then shall we all evolve as technologists.

Thanks for reading!

Untold Stories

Pondering the Pitfalls of Product Ownership

The Product Owner role is a challenging one to understand. I often hear people describe this position as the Scrum equivalent of a Business Analyst. This may be in part due to the established relationship between requirements and stories.

These roles are not the same. Product Owners are responsible for ensuring all features proposed fit with the overall product strategy. Meanwhile, Business Analysts propose requirements without necessarily taking the wider roadmap into account. The Product Owner role, as defined in The Scrum Guide, is responsible for the product backlog. The word owner highlights a level of accountability that an analyst does not possess.

Beware of some of the traps I’ve found with Product Owner

Confusing these roles is hampering the building of our software. I’ve seen first hand that we are struggling to identify suitable candidates on which to instil the honour of Product Owner. Here I discuss some of the traps triggered when identifying Product Owners, and the characteristics that people need to succeed in this role.

Cluster One

One common challenge faced by many of our teams is having a dedicated Product Owner. Historically, we have selected representatives from our client base to fill this seat. The typical profile has been a lead in that particular area with significant knowledge of current processes.

The key struggle we have with our Product Owner strategy is their lack of dedicated time. They have a day job that takes priority. When the going gets tough at work, their Product Owner responsibilities are the first thing that is dropped. This leaves development teams struggling to get the support they require on both ongoing development items and upcoming prioritisation.

It is important that the Product Owner and development team work together to build out these features. To guarantee development teams receive the support they need, and vice versa, Product Ownership must be a full time job. Only by having one person continually dedicated to the cause will ownership be guaranteed.

Missing Pieces

Another difficulty with the parallel role is that their expertise may apply to one small segment of a larger process. The expertise of our nominated team leads has proven to be immensely valuable in the identification of new features. Nevertheless, they are unlikely to know the intricacies of the next stage once they have handed over their output to the next team in the chain.

Choosing someone previously responsible for part of the puzzle introduces a level of bias. They often provide stories directly related to their role. Furthermore, they can miss proposing the enhancements that will benefit downstream stages, which also require representation.

Product Owners own the entire process puzzle, rather than just a single piece

Elimination of these predilections is important to obtain a holistic view. Through story identification, we can recommend process optimisations to identify the client’s true needs and remove manual stages. A dedicated Product Owner will be more likely to propose such enhancements.

I’m So Curious

Understanding of business process is vital to being an effective Product Owner. Starting with a complete comprehension of the business domain can introduce complacency.

Processes evolve over time. The funding process that I’ve come to know over the past few years has evolved. I’ll be the first to admit that keeping up to date with these changes can be a struggle. The knowledge I gained when I first joined the team remains useful. However, to provide useful solutions to our users, I must keep asking questions. A level of smugness can kick in if Product Owners don’t keep probing procedures at every stage.

Techniques such as User Story mapping can help Product Owners to ask the right questions

Effective Product Owners must be curious. They need to have the initiative to ask both the obvious and obscure questions. These techniques can be used in conjunction with user story mapping techniques to extract key features. This ensures that when developers ask the same questions when building these features, they are able to obtain the answers they need.

That’s How People Grow

Product Ownership is a massively underrated role in some regards. Part of the reason we struggle to attract full time collaboration by curious individuals is it doesn’t receive the recognition it deserves. Like any role, to attract strong candidates we need to show their work will be appreciated.

Organisations should ensure there is a career pathway for all role types, including Product Owner. The ability to manage a backlog and support development teams is not a trivial task. The best candidates don’t have to come from a business background. Strong technical individuals able to facilitate with users will make for excellent Product Owners if they see the role has growing space.

Product Owner is a superhero role that deserves more respect than it often earns

Adhering to the guidance outlined in this article will reduce the chance of encountering these pitfalls. Stop seeing Product Ownership as a secondary role. For people to aspire to be Product Owners, it needs to be seen as a viable role where colleagues will receive recognition, and be able to progress.

Thanks for reading!

Sound of Silence

The Effects of Work Environment on Developer Productivity

Space may be the final frontier. It may be wide and open. Or even closed and confined. In the software development world we often focus on tooling and its effect on programmer productivity. This crazy distributed world is encouraging us to think less about the importance of physical workspaces.

Our work environment historically hasn’t been given much focus. Only when Peopleware by Tom DeMarco and Timothy Lister was published in 1987 were the social aspects of software engineering popularised. Today the notion of Agile workspaces is being advocated for fostering collaboration and productivity. The question we should ask ourselves is what environmental factors support agility?

What attributes of our working environment make us more or less productive?

I read Peopleware in university when examining personality composition of productive teams. Yet, the lessons regarding workspace and its effects are another vital consideration. Changes to my own desk positioning have caused me to re-investigate the insights proposed by Tom DeMarco and Timothy Lister. This week I’ll outline my musings on the office surroundings, and how it affects our productivity.

White Noise

Noise travels. Having a multitude of colleagues speaking on the phone leads to an incessant buzzing travelling around the floor. Individual conversations on the floor contribute to the swarm of bees buzzing around your head as you work. Software engineers perform very thoughtfully intensive work. Concentrating on writing code, reading code, or completing any intellectually gruelling tasks requires peace and quiet.

> Your folks are intellect workers- they need to have their brains in gear to > do their work, and noise does affect their ability to concentrate. > > Tom DeMarco and Timothy Lister, Peopleware: Productive Projects and Teams

Separation of collaborative and individual spaces is crucial. Don’t cram floors with developers like battery hens in cages. They need some personal space to focus on computationally intensive tasks. Yet they also need booths and collaborative spaces to encourage working together.

Programmers shouldn’t need to utilise headphones to help them complete thought intensive tasks

I’ve never been one for continually sitting in silence. Nevertheless, through disregarding the babble we are enforcing every developer to require a set of noise cancelling headphones to be productive. Introduction of noise reduction mechanisms on the floor itself is one of the latest advancements that should be adopted. It would certainly have been useful of late, where I could hear colleagues from my dark corner on the opposite side of the floor.

Let’s Get Together

Whether you work to live, or live to work, we spend the majority of our week in the office. The office needs to feel homely yet not encourage leaving at an unreasonable hour. Being human, software engineers will still want a fixed location to flock to every day. My experiences with hot desking early in my career emphasised that human beings are creatures of habit. The majority sat in the same desk everyday. Their lockers were only filled with their non-essential hoardings when visitors needed a desk. Flex desking possesses primarily fiscal benefits as you have less empty desks in the case of sickness and holidays. However it does depersonalise individual work settings.

Sitting teams away from each other is not as good for the pedometer as you may think

Proximity to your team can have a strong impact, regardless of organisational strategy. Strong teams have diverse personality sets that will gel together, but that is not the only factor affecting their productivity. Offices shouldn’t be treated as a peak-time tube train, cramming new arrivals into every free centimetre of space. It is a misnomer that colleagues will walk to your desk irrespective of where you sit. Even if they are counting the steps on whichever pedometer app or device they use. Instant messenger applications become the default communication mechanism, which can leave segregated developers feeling isolated.

Teams should be placed in collaborative facing groups rather than endless rows of desks. Areas should also by extensible to allow teams to grow. Like blocks of memory, slotting new arrivals into the first available slot rather than encouraging concurrent access is not a great impression to set for new engineers.

Where I Draw the Line

With an emphasis on co-located teams within many Agile methodologies, collaborative spaces are required to foster fraternisation. To encourage innovative solutions means your work environment must include tools to help encourage ad-hoc creative thinking. Tools must be openly available without the need to lock coders in conference rooms.

> You may be able to kick people to make them active, but not to make them > creative, inventive, and thoughtful. > > Tom DeMarco and Timothy Lister, Peopleware: Productive Projects and Teams

Many Agile spaces boast every wall being a whiteboard, as well as smaller versions at developers desks. Having boards only in meeting rooms can introduce challenges, especially when you have a shortage of quieter spaces for deep thought. Even windows can allow sketching of new ideas with the right pens. The added bonus of getting creative with your collaborative space is programmers can bask in natural sunlight for the few months per year that we have it.

Windows and whiteboards can be used for collaboration and design, not just menus!

The little things are important to developers. Engineers crave more monitors, better mice and keyboards. Even the specification of the coffee machine can prove to be a source of contention, as I’ve found of late.

With the exception of the pricey coffee machine, the start up paradigm of giving coders choice over their tools is something us larger organisations should consider. Having them build their own PC or laptop spec will not be scalable. There is no reason that personal budgets for mice, keyboards and monitors couldn’t be adopted to give programmers the tools they need to operative productively. Such mechanisms must be applied consistently to prevent the spread of animosity.

Common People

There are far more productivity enhancements I can recommend based on my time in the relegation zone. It is important to regularly evaluate our work environments and experiment to determine which options will work for the engineering collective. Measurement of individual productivity would be the best mechanism to determine if developer productivity is being impacted by their surroundings. Once the fix is identified, it should be adopted across the entire group to prevent feelings of resentment developing.

> When the office environment is frustrating enough, people look for a place to > hide out. They book the conference rooms or head for the library or wander > off for coffee and just don’t come back. No, they are not meeting for secret > romance or plotting political coups; they are hiding out to work. > > Tom DeMarco and Timothy Lister, Peopleware: Productive Projects and Teams

Peopleware outlines several strategies employed by people unhappy with their environment. Looking out for these signs can help identify workspace issues. One of the notable approaches that is easy to spot is employees diving into offices or conference rooms to get work done. This is a more drastic mechanism than the more common headphones on strategy. Another possible strategy is working remotely more regularly. This can also be an indication of developer frustration. Managers should be on the lookout for these warning signs.

Measure developer working habits both in and away from the office to determine space effectiveness

Dissatisfaction can stem not only from the work itself, but also developer surroundings. Regardless of profession, people want to go home every day feeling effective and accomplished. Be mindful of the small environmental factors appreciated by programmers. Even the cackle of colleagues echoes across a packed engineering floor.

Thanks for reading! Do also check out my follow on piece on workspace impact on non-occupying stakeholders.

This Masquerade

Can Software Craftsmanship be Nurtured?

Craftsmanship is not limited to carpenters. Even suggesting it is limited to the building of a physical construct is an ignorant statement. My inner perfectionist always attempts to guide me down the path of doing the right thing in everything I do. Naive as it sounds, this also applies to the software that I build. Craftsmanship is defined as the quality of design and work shown in something made by hand. Users do form subjective opinions on the quality of the software they use.

Building of quality software requires a degree of mastery from our engineers, with experience of using the right tools

Software is not tangible, so measurement of our level of professionalism is challenging. Nevertheless, that doesn’t mean we can just hack it together. Wiser people than me have highlighted the importance of building software the right way. This week in particular, thoughts around the Agile community and their relationship with craftsmanship have triggered considerable debate. Here I ponder how to identify software artisans, and whether mastery of these principles can be nurtured.

Let Me Be The One

There are indeed individuals already out there that take immense pride in building high quality software. All technology firms want to hire the best talent. Those who continually strive to increase their software development acumen are the talent organisations wish to attract. Is it safe to assume that our hiring process will distinguish between cowboy coders and professional programmers?

Identifying a passionate technologist doesn’t guarantee that they will build software the right way. People may say the right things in an interview, but it’s important to extract if potential engineers practice what they preach. Beware the situation of an interview turning into a game of buzzword bingo. Asking probing questions is the sole method of validating whether they have experience in applying these techniques.

Ensure that any prospective candidates understand the techniques they discuss and are not playing buzzword bingo

To measure the mastery of any potential engineer, live coding exercises in interviews should be mandatory. Our recent hiring has focused on coding exercises both before and during on-site interviews. Nevertheless, this may not be enough. You can discuss design and implementation considerations, but in a few hour interview candidates are less likely to showcase practices such as TDD. Only once they are producing code as part of your team can you truly assess their degree of professionalism.

It’s Going to Take Some Time

Once these sprightly software engineers have been integrated into the team, managers are able to critique their level of craftsmanship. The true test is when they are put under pressure to deliver. Agile methodologies such as Scrum and Kanban provide techniques to ensure a constant work rate. Limiting by time or concurrent tasks is intended to protect programmers. Regardless, I still see managers pile on the pressure to deliver user value. It suggests we are treating programmers as mindless zombies, responding to every order by frantically rapping on the keyboard.

When the going gets tough, software virtuosos will be mindful that they are accruing technical debt

I’m afraid to admit I’m also guilty of this phenomenon. To meet the deadlines imposed by managers, developers are delivering features far too fast. With such velocity, quality is compromised. I’m not just talking about conceding on test coverage. That is merely one attribute that limits the ability of our software to stand the test of time.

Insufficient discovery time will result in building of features that may not scale to the intended use case. Bad smells will also creep into the code. Any artisan engineer will tell you compromising on craftsmanship in this way is not worth the accumulation of technical debt. Like any mortgage, you will have to pay down your debt eventually. Rather than being threatened with foreclosure, the system will become difficult to maintain. Working on indebted code bases fosters developer frustration that may ultimately result in your better engineers leaving.

We’ve Only Just Begun

Not all engineers will be skilled software virtuosos from day one. I certainly wasn’t when I first walked in the door as a bright eyed graduate seven years ago. I’m still working on building my own skills. Talent should be hired not only for the skills they have, but their potential to improve and become pragmatic programmers.

Craftsmanship is fostered through culture. An established team can still be encouraged to improve their craft if nurtured. Reading is vital in our quest to improve as software engineers. Although practice makes perfect, only writing code will never make you the best developer you can be. Honing your craft requires seeking additional sources of wisdom, and contemplating the ideas projected. Books, blogs, tweets, tributes. All will provide insight. Teams should become comfortable sharing resources. It is not just a managers responsibility to assign out reading material. We’re not in school anymore kids!

With a multitude of resources out there, including but not limited to books, teams can share and grow their expertise together rather than alone

Writing code regularly is essential. Continually assigning the same tasks to the same developers time and again will encourage skill stagnation. Personal tinker time is also a great mechanism for supporting the technical development of engineers. Michael Lopp advocates keeping a Tinker List of the technologies you wish to investigate in Managing Humans. Managers and programmers alike need to experiment with new technologies. They must also scrutinise the inner workings of frameworks which they currently use. Dedicate regular time to trying out technologies and techniques. Only then can we continue to master our craft.

Thanks for reading!

Shuffle The Deck

Shaking Up Our Stand Ups

Change is inevitable. That would be my executive summary of the past three months. Rather than continually follow a plan, we need to be receptive to change and adapt accordingly. With life being uncertain it’s only logical that we need to be comfortable taking chances. Being comfortable with continuously improving the format of our Agile ceremonies to is imperative for team empowerment.

Mors certa, vita incerta

Philip K. Dick, Do Androids Dream of Electric Sheep?

So far this year I’ve lead two different projects with different goals. Yet both required a reboot of their stand-ups to improve collaboration. This week I discuss the emerging trends of stale stand-ups, and reflect on how our attempts to reinvigorate daily updates have affected team collaboration.

Glasshouse Tarot

The majority of this audience should be familiar with that age old stand-up pattern. It is the mark of Agile evangelism that is permanently branded onto our minds. For those less knowledgeable each participant outlines three key points:

What tasks they completed yesterday.
Their proposed agenda for today.
Any blockers that will prevent them fulfilling today’s goals.

The traditional stand-up format encourages discussion of past, present and future exploits by each person

Think of that scene in Live and Let Die where Solitaire predicts Mr Big’s fate using the Witches Tarot Deck. Yes, I know which deck it is as I own the same set. Colleagues on a stand-up call out the past and present activities along with future challenges in much the same way. Regardless of your beliefs in fortune telling, it is worth reflecting on how effective the readings are in any format.

Lazy Poker Blues

Part of our problem was the format had become far too predicable. The regular round robin routine meant developers switched off during stand-ups and simply waited for their turn. Their updates were succinct, yes, but key details such as blockers were often missed. Issues were often voiced after the call when the relevant SME was contacted for assistance. As a lead, tracking progress with these unknown blocker variables became impossible.

With our team being distributed, over-reliance on phone also inhibited updates. Team relationships are exceptionally challenging to nurture across regions. You don’t truly connect with someone until you look then square in the eyes. Spotting their tells of frustration or concern solely based on tone is difficult.

We may have become a society glued to our devices, but a stand-up is not the time to be checking social media

Indirectly, programmers focus on our stand-ups was far from stellar. While waiting after giving their update, I could see local engineers browsing on their phones. If their focus was on work, they would be burried in their email inboxes. This lack of attention is clearly disrespectful to your colleagues. From a team work perspective it was also leading to a communication disconnect. Gathering in rooms certainly did help improve things for a short time. Focus continued to waver.

Gambling Man

The stand-up routine is considered sacrosanct by many. In these circles it’s destined never to change. I’m more experimental myself. My regular reading one morning a few months ago revealed a Eureka! moment with a story oriented stand-up approach. If stories are the key features of focus for delivery, why are individuals the centre of attention?

After discussion in our retrospective, we collectively agreed to give this new format a whirl for one sprint. The approach was to apply our favourite three elements to the stories instead.

Focusing on stories over individuals should foster collaboration and make stand-ups more collective focused

Like any change it took time for individuals to adjust. There is a danger that you inadvertently lengthen your stand-ups if discipline is not enforced. This did happen initially. With effort, we managed to shift back to our average 10 minutes stand-up duration.

Developers reported several key benefits. Status of work, including blockers, became more transparent. Assistance was offered for blockers quickly, resulting in story subtasks moving across the board more rapidly. Nevertheless, the biggest result was the engagement between colleagues. Programmers were no longer distracted by other tasks. As my job is to keep my engineers happy and engaged, this was a massive result for me.

Play Your Cards Right

Further validation of this method came a few months later. Following an organisational restructure, this rock star team was split in two. The teams we were absorbed into were following the good ol’ standup routine.

After a couple of weeks, engineers who were part of the original experiment began raising concerns. They were seeing the same issues in their new daily stand-ups. They were recommending that the same approach be adopted in both projects. Since their proposals, other teams have embraced the new format. Feedback from these teams are finding the story first approach better facilitates collaboration. In my eyes this is a fantastic validation of the initial experiment.

Teams should use their best judgement to continuously improve all aspects of their process. stand-ups are sacred, but not off limits!

In this game of chance, the developers have won over the house. The Agile space is filled with numerous different techniques that teams can use to solve problems, regardless of which methodology you use. Some consider it obscene to tinker with the key ceremonies. Shake off any reluctance and be comfortable taking a gamble.

Thanks for reading!

Test of Time

Compromising Test Coverage Under Pressure

With life, the universe and everything, everyone has their own standards. Perceptions of quality are different between individuals. Agreeing a common definition of done across the team is an important initial step in any Agile journey.

When the going gets tough, ensuring each feature is built to these principles can be challenging. Even the most well-intentioned developer can fall foul of shortcuts. When managers pile on the pressure, programmers attempt to meet expectations by compromising on best practices.

How do we make sure our teams take the correct route under pressure, rather than a shortcut?

Unfortunately for us, this has included test coverage. This key criteria of our definition of done has been under threat. Recent adoption of minimum coverage gates prompted several discussions around temporary adjustment of these metrics as engineers felt functionality was blocked. Here I reflect on the contributing factors that force our programmers to deviate from the right path, and how to lead them down the correct route.

Begin the End

If we are compromising on test coverage when under pressure, it is safe to assume we are not writing our tests first. We advertise ourselves as practising Test Driven Development, or TDD for those in the know. When it comes to the code review stage, there are occasions where feature and project coverage doesn’t meet the minimum percentage agreed in the team definition of done.

For the past 3 years we have been aggressive with our adoption of Behaviour Driven Development, a subset of TDD. We are exceptionally fortunate that we have client representatives writing behavioural scenarios for all new features. A story is not ready for development if we haven’t received a set of scenarios. Despite being available from the outset, encouraging developers to write tests first is still proving troublesome.

Engineers can struggle to write tests first when adapting to the TDD circle of life

Ideally we would want them to follow the TDD approach of writing a failing test first and implementing the least possible amount of code required to make the test past. Writing effective tests was not given much focus in my Computer Science degree course. Speaking to students and recent graduates, it still appears to be the case that they have little experience writing unit tests as part of their studies. Furthermore, they generally have no opportunity to write integration tests. It is an arduous process to change the mindset of writing tests last. I’ll admit I still labour over following the TDD cycle.

Nevertheless, the benefits are numerous. Many are documented across the Web, however one often overlooked advantage is the scenario’s dual purpose as feature documentation. Lengthy user manuals akin to War and Peace are no longer viable for clients who want to start using our software immediately.

Out of Time

Another aspect programmers and technical leads alike find excruciatingly difficult is providing accurate estimates. Humans struggle to determine how long things will take. Regardless of whether they include the writing of integration and unit tests in these timelines. Against their better judgement, developers will provide estimates that are not concrete. Call it the programmer curse of perpetual optimism. Development will most likely take longer than anticipated as they are tormented by library conflicts, logic errors and other blockers. Not adding testing effort will only add fuel to the fire.

A common misconception is that an estimate is an exact measure of time from which we can project a delivery date. The noun estimate is defined as an approximate calculation or judgement of the value, number, quantity, or extent of something. Approximate is the key word in this definition. Despite our best intentions to include our testing effort, we often overshoot.

Estimating effort is exceptionally difficult, but cutting corners to meet deadlines results in users finding more defects

Sounding the trumpets at the grand unveiling of the latest and greatest tool may appear to be the right thing to do in this instance. Writing unit and integration tests does not prove the absence of bugs. Manual user testing will not verify that functionality is defect free either. Arguably they may find increasingly more defects in their testing cycles if this pattern continues.

Why should our customers be handed potentially substandard systems for which you don’t have time to write automated tests? Appreciation for the time of others is an important aspect of compassionate collaboration. By selfishly saving ourselves time by avoiding writing tests, you are suggesting it’s acceptable for our clients to spend more time searching for system shortcomings. A client’s place is not on a pedestal. Developers and stakeholders should work together. But we must respect each other’s time.

Crossing the Threshold

Although our Happy Developer Guide advocates minimum coverage across all of our code bases, tools are required to enforce this benchmark. Reliance on developer diligence is not enough. Over the past year we have created several new projects, initially without any mandated thresholds on test coverage.

Adding gates after the fact can foster frustration as programmers have to pick up the pieces of others not adhering to these axioms. Collective code ownership is a key quality of strong Agile teams. Each engineer should follow the Boy Scout rule, and leave the code base better than they found it.

Like a camp ground, we should leave code better than we found it to preserve its natural beauty

To balance developers differing principles, you cannot rely on the strong, proud engineers to write the additional tests required to bring your code repository up to scratch. Avoid this animosity by including these limits from the beginning to encourage compliance to your coverage commandments.

Thanks for reading!

A Fine Blue Line

Evaluating Time to Market for Grid and Chart-based Features

Building banking software exposes us to a lot of numbers. Balances, ratios, percentages, rates, they are littered throughout the systems that we create. The difference between data and knowledge lies in context. Shouting 42 from the rooftops is not very meaningful until you’ve read The Hitchhiker’s Guide to the Galaxy by Douglas Adams.

To discern knowledge, we need to unite data with context

It’s unsurprising that the majority of banking applications centre around massive grids exposing expansive arrays of digits. Showing scores of figures is the easiest option as we see our goal of presenting the right number. We forget that we should always show the correct values, regardless of representation. Discerning meaning from larger data sets is exceptionally challenging.

Not so recent events have got me contemplating about why we always settle for grids. It is regularly seen as the easy way out. Moving on from the human aspects of development, this week I focus on adoption of visualisations. I present my thoughts on our trepidation of utilising them over traditional tables.

Time After Time

It is a common misconception that graphs take significant time to develop over tabular views. Adoption of agile practices into our software development processes has granted us numerous gifts. To date, our focus on small, frequent releases has resulted in a large amount of new features being made available to our clients.

Once in the habit of producing new functionality regularly, we often impose pressure on ourselves to deliver increasingly more rapidly. This strain will influence our design decisions. However, the notion that charts are more challenging to construct is a fallacy.

Poor Excel skills aside, this tool highlights that the underlying data sets of charts are also tables

Working in banking, my clients exhibit a strong preference for Excel, and have a far better knowledge of the tool than I. It is an essential tool in their toolbox for conducting their daily responsibilities. The charting feature within Excel transforms tabular representations into a chart. The values underpinning graphs and grids are essentially tables.

By using one of the multitude of charting libraries available to us, we can transform these two-dimensional arrays into valuable visualisations using similar logic. My experiences over the last few years have shown that development time for charts and grids are on par. Our team regularly delivered chart and table based controls in a single development cycle. Furthermore, with definition of a common contract, the time to market has been further reduced. We just need to identify the use cases for which one is suitable over the other.

One is the Loneliest Number

With time no longer a factor, let us consider how to identify the best mechanism for presenting content. There is an inherent risk while building data heavy applications that we become monopolised by numerals. Accuracy is monumentally important. But to support our quest for correctness we must ensure the tools that we create promote a workflow that can allow users to achieve a quantifiable goal or benefit. Throwing a matrix of bamboozling digits together is easy for programmers, but can lead to information overload.

Endlessly searching through figures to find meaning takes its toll on people. To propose the best solution to our clients, we first need to identify the true problem. Design thinking is vital to identify the key goals of those using the system, and establish empathy with our users.

Design Thinking can be used alongside other development frameworks, including Agile, to help identify user workflow and value

The key goal of the empathise and design stages is to develop an understanding of the current challenges that our system should be striving to address. This is achieved by observing people and asking questions. What are users actually trying to achieve? What is that value actually for? What decisions and subsequent actions will be triggered from the knowledge invoked by this number? If it’s just a single integer, then show the value with labelling for clarity. If you need a few more, consider using heatmapping or highlighting techniques to show users where to look. The domain is critical to allow benefit to be discerned from the system.

Draw the Line

Once we have developed an understanding of the key system goals, that’s when the fun really begins, at least for me. Brainstorming and sketching out ideas may initially appear time consuming. However this is a misconception that can be addressed using low fidelity options such as pen and paper, or even Excel!

Ideating and prototyping with simple techniques such as sketching will prove the pen is mightier than the sword

Often we start with utilising simple visualisations such as bar and line charts. Such mechanisms are useful for identifying peaks and trending across our statistics. Once we start charting there is a danger that we only use these techniques, regardless of the observed objectives.

Researching alternatives will help us propose suitable solutions for our data sets. Seeking out innovative ideas will help you realise that information is beautiful. There are a few rules of thumb to help you on this journey. Sankey diagrams are good for showing usage flows and their composition. Directed graphs are fantastic at visualising relationships and hierarchies between key components.

As technologists, we strive to continuously improve our processes to produce valuable, scalable, maintainable software. Nevertheless, the features we build should be fostering continuous improvement to our client’s processes. Let’s propose the right control to solve the problem, rather than deceiving with a deluge of digits.

Thanks for reading!