Learning with Architecture Kata: Workshops & Recruitment

Tags

architecture, architecture groups, c4, kata, recruitment process, software, software architecture, solution design, ThoughtWorks

Having completed a worked example of the kata over the 7 previous articles, let’s look at how we can use the concept of kata as both a workshop activity and as a recruitment tool…

Background

This is part of a series of articles about how I use Architecture Kata as a capability building exercise and a recruitment tool at ThoughtWorks.

Here are the previous articles in the series:

• Introduction
• Roles
• Responsibilities
• Business Processes
• Assumptions
• Solution Context
• Solution Components

All these articles will be focused on the same kata; “I’ll Have the BLT“. I’ve chosen this one because it’s in a domain (retail and food ordering/delivery) that most people have some innate understanding of, from either a consumer and/or employee perspective.

Recap

Below is a quick summary of what we’ve covered over each of the previous 7 articles. And if you’ve been studiously following along, you’ll see that there’s quite a bit of time needed to work through these sections, identify and reflect on the assumptions you’ve made along the way and iterate over your solution. All in all, it’s a great activity for a rainy day stuck in Covid-19 isolation!

However, there are other ways of using kata which provide different outcomes which still include most – if not all – of these steps. The two approaches I speak of are:

1. Using kata in a time-boxed workshop to build solution design and collaboration skills within a team,
2. Using kata in recruitment to identify solution design skills in candidates.

Workshop Kata

I’ve run these sorts of workshops for many groups here at ThoughtWorks and they largely follow the format described by Ted Neward, although I do have some slight tweaks to his process:

Code of Conduct

To make the workshop a safe and inclusive space for participants, irrespective of background or degree of extroversion/introversion, I’ve settled on the following Code of Conduct for my kata workshops:

In short, it says: don’t be a dick, do be inclusive, focus, and criticise ideas, not people.

Group Size

Largely due to the number of possible communication paths in groups of various sizes (see below), my ideal group size for these workshops is 3, with a preference to groups of 2 rather than 4 (but preferring a group of 4 to people working individually). With groups exceeding 3, the group often splits into subgroups and then suffers from late integration of work.

https://www.triloggroup.com/developing-peer-to-project-communication-with-social-project-management/

Time Constraints

Within ThoughtWorks, I typically time-box these workshops to 1 hour (which is a tight stretch, but achievable) and use the following time guide for the activity:

which looks like…

If the group(s) are doing their first kata, I’ll be more firm with these time limits to ensure they pay some attention to the role, responsibilities and business processes instead of diving straight into technical solution diagrams.

If it is a single group participating, then I’ll drop #6 and reallocate that time to #5. Sometimes if the group is doing a kata for the first time and I know they’ll have more opportunities (e.g., I’m running a series of these workshops with the same people), I’ll also drop #6 just to take away the concern of sharing their kata with a broader audience.

If I have the luxury of more than on hour (e.g., 90-120 minutes), I’ll make sure to include lots of time for sharing kata between groups. There are always great learning moments when groups see how common/different other solutions are to the same problem. This is basically the Peer Review Phase as described by Ted Neward.

The Moderator

When I play the Moderator, I’m a lot more lazy than Ted Neward suggests:

“The Moderator is your customer, your boss, your project manager, your IT ops guy…. Basically, the Moderator is everybody except you.”

https://archkatas.herokuapp.com/rules.html

My default Moderator behaviour is to push the groups to make all the assumptions necessary to build a suitable solution to the problem. Specifically, I don’t play the role of the Customer, largely because of the logistical issues with doing so in a workshop with multiple groups, but also because I want attendees to think deeply about the problem domain.

The Voting Phase

I don’t do it. Groups are perfectly capable of self-concluding how well their solution fits the kata without peer voting.

Multiple Kata

If I have the opportunity to run the same people through multiple kata exercises (normally over a period of several days/weeks), I take the following approach:

1. Start with an accessible kata (“I’ll Have the BLT” works well in this respect, as does Check Your Work and You Look Good In Print.
2. Run a second exercise with a different kata (same groups or different ones) and the same approach, but preface it by announcing a specific focus on a cross-functional requirement. Some kata are better suited to specific cross-functional requirements than others. For example:
   • Gird The Grid -> scale, security
   • Experimental College -> data privacy
   • Going Going Gone -> performance
3. Run a third exercise with a different kata (same groups or different ones) with the same approach, with a focus on a different architectural style. For example, switch from predominantly synchronous integration to message-based asynchronous integration.
4. Return to the original kata as used in #1 (same groups or different ones) and compare the quality of the resultant solutions. Hint: they should be far more detailed and suitable from #1 to #4.

Recruitment Kata

If you end up in the ThoughtWorks recruitment process (at least for Australia) and are an experienced engineer, there’s every likelihood you’ll have a kata interview at some stage. Effectively these similar to the workshops described above except:

• You are in a team of 1
• There are less need to pursuea formalised process (e.g., Roles -> Responsibilities -> Business Process, etc) to arrive at the solution
• There will likely be more questions from your interviewers challenging your assumptions and design decisions along the way.

If you want to use kata as part of your recruitment process, here is the advice I give people who are conducting these types of interview for the first time:

Areas of focus

Kata gives the ability to assess a candidate across a number of areas:

• On-the-fly solution design (including communication skills)
• Technical breadth
• Technical depth

Assessing each of these areas requires forming answers to a variety of questions through the interview as the candidate’s solution starts to take shape.

Solution Design

How well do they convey their solution design thinking? Is it overly technical? Is it overly business-focused? For example, have they identified the key actors? Have they pieced together a reasonable business process flow involving the actors, capabilities and potential systems?

Is there a logical progression to the way they decompose the solution? Or are they jumping around randomly making it hard for the audience to follow? Have they identified the key capabilities that need a home in the solution?

How comfortable are they with speaking their mind? Do they seem flustered or generally comfortable/confident with the exercise itself?

There are usually statements in each kata which have no real impact on your solution – have they identified these and explicitly discounted or deprioritised them?

Have they brought any relevant domain knowledge to the problem? Have they mentioned typical constraints for the domain? Likely drivers for the solution? Is their natural domain knowledge a good fit for the solution? Have they expressed knowledge of relevant local or international regulatory bodies/rules impacting the domain?

Being aware of the time constraints, have they started building the solution early enough in the interview, or spent too much time digesting the problem itself?

Technical Breadth

A well considered solution to most kata could include aspects of:

• Software design
• Hardware selection
• Database design
• Application security
• Hosting
• Network security
• Operational concerns (logging, monitoring, etc)
• Data engineering
• Testing
• Deployment

Time constraints will prevent candidates touching on all of these aspects, but strong performers should be capable of speaking intelligently to most of them. As interviewers, you may want to steer them in certain directions to test their knowledge in one of these areas.

Technical Depth

For the non-practising candidate, this is the area where their lack of recent engineering experience will be most apparent, but it is still worth understanding where their knowledge stops.

Often the solutions produced by these people will lean heavily on project experiences they’ve had, so they might end up squashing a known tech stack awkwardly into the kata domain.

Good deep pockets of exploration can be found in the “I’ll Have the BLT” kata by asking the candidate to focus on:

• The data model – particularly around customer ownership and promotions
• Integration approaches – particularly when dealing with existing walk-in customers and online orders
• Inventory management – to allow promotions to minimise the amount of waste

Recruitment Kata – Conclusion

Kata interviews tend to favour generally confident speakers (who wont be flustered with the dual need to think and explain) who can draw upon enough experience from a “close enough” project in their history.  If you think this is the case, try to nudge them off the beaten path and into areas they may not have experience with.

Next Steps

It’s all over to you now, dear reader – pick your first kata and enjoy!

Did you find this article useful/interesting?

⭐

Rating: 1 out of 5.

Learning with Architecture Kata: Solution Components

Tags

architecture, architecture groups, c4, kata, recruitment process, software, software architecture, solution design

With our Context Diagram to support us, it’s time to move onto the last part of the kata – the Container Diagram, which gives us a more detailed description of the logical solution architecture

Background

This is part of a series of articles about how I use Architecture Kata as a capability building exercise and a recruitment tool at ThoughtWorks.

Here are the previous articles in the series:

• Introduction
• Roles
• Responsibilities
• Business Processes
• Assumptions
• Solution Context

All these articles will be focused on the same kata; “I’ll Have the BLT“. I’ve chosen this one because it’s in a domain (retail and food ordering/delivery) that most people have some innate understanding of, from either a consumer and/or employee perspective.

The C4 Model Container Diagram

Let’s start with a quick look again at where we ended up with our Context Diagram from the last article. Remember that we reduced this diagram from the initial draft and removed many of the actors that had been prominent in our thinking up until this point.

C4 Context Diagram

The following aspects are missing from this diagram: we want to ensure they make it into our Container Diagram:

• Showing the connections between the System and other relevant actors from previous articles
• Decomposing System into a lower layer of technical components, including our thoughts around subsystems (which might result in separately deployable components)
• More specificity about the nature of the integration between these components
• Some hints to what technology could be used to realise the components.

The C4 Container Diagram

By the time you get to this level of thinking about the solution, you probably have some idea of what dominant architectural style you plan on using. These thoughts might be based on your experience, current industry trends or convention within your employer. In this case, it’s all three as I’ve decided to build the solution using microservices. Similarly, you have likely decided on a hosting platform and – in order to keep the up-front costs down for our cost-conscious customer – I’ve decided to use AWS. You’ll start to see these decisions reveal themselves in parts of the container diagrams to follow.

The first draft of our container diagram appears below. It still looks pretty rough, but there are some aspects to it which are worth highlighting:

• There are three subsystems represented; Promotions, Ordering and Order Management. The diagram shows that these subsystems are largely used by only a single actor within our system; Marketing -> Promotions, Customer -> Ordering and Cashier -> Order Management. The ability to cleanly associate these actors with only a single subsystem gives us confidence that we have these boundaries drawn correctly. We could also start to think about different cross-functional requirements for each of these subsystems as well… does the Promotions subsystem need to scale to the same level as Ordering? Does it need to be as highly available?
• Each of the subsystems includes a Front-end and Back-end component, as is typical of modern web application architecture where browser-side components are served from a static content repository and communicate to back-end services via an API.
• Where databases have been identified for the Promotions and Order Management subsystems, they are only connected to the corresponding back-end services. Specifically, the Customer back-end component persists order information via the Store back-end and not by integrating directly with the Store database.

Version 1: Components and actors

The next version of this diagram makes a few changes to the components and adds a lot of detail around the implementation and integration decisions. Apart from adding depth to these aspects, I’ve also had a rethink about the Promotions subsystem. Let’s talk about this change…

Version 2: Integration and implementation details

Headless CMS and publishing Promotions

I decided to host an open source Headless CMS behind a bespoke custom API to support the minimal requirements for promotions that will be needed. With the right choice of CMS, much of the drudgery of implementing Promotions management will be included out-of-the-box. There might be some rough edges in the user experience, but given budget constraints, hopefully these issues will not be blockers.

The Promotions API will also be responsible for publishing promotions to the Ordering system to make them available to customers. This publishing flow suggests some form of persistence in the Ordering system which I haven’t shown at this point. I plan to leave this as an implementation detail as the promotion data is only readable by the Ordering subsystem, although it would presumably need to be used both as input for rendered information in the front-end and also for validation and pricing decisions in the Customer back-end. To be honest, there is a potential hornet’s nest of requirements here that could make this quite tricky to design correctly, especially if both rich content (e.g., images) and data representations of the promotions are needed. Promotions are also often time-bounded (e.g., “every Tuesday…”, “for this month only…”), which implies either a time-based promotion publishing flow or having the Ordering subsystem being capable of expiring promotions.

We’ll revisit the Promotions subsystem in the next version of this diagram.

Version 3: Promotions subsystem updates

The second iteration on the Promotions subsystem has resulted in further changes:

• The removal of the Promotions front-end in favour of using the default UI provided by the CMS. Most headless CMS still have a Content Management capability, even if there is no matching Content Presentation capability.
• An assumption that expiring promotions can be handled via notification directly from the CMS, which triggers the Promotions Publication API (note: formerly the more generically named Promotions API) to update the Customer back-end.
• The addition of an explicit call from the Customer front-end to the Customer back-end (“Retrieve promotions”) to retrieve the live promotion data. This call has been added for further clarity around how this information is rendered.

Outside of the Promotions subsystem, there are a couple of areas I want to refine for the next version of this solution:

• The integration to the Docket Printer. I don’t really know how this is going to work as we want dockets to be printed automatically when confirmation of an order arrives from the Customer back-end and the printer is physical piece of hardware located inside the store itself.
• The robustness of the critical path of Order -> Payment -> Confirmation -> Delivery… are there single points of failure along this path which we need to focus on?

Docket Printing

Below is the fourth version of our container diagram, with a particular focus on integration with the Docket Printer. I must admit the solution in this diagram is badly in need of a technical spike to qualify, but the idea is roughly:

1. Create a new web app (Docket Printer F/E) which is always running on a browser in-store. This could be on an iPad, or any other device connected to a local network inside the store.
2. Create the local Docket Printer as a printer on the device hosting the Docket Printer F/E.
3. The Docket Printer F/E constantly polls (i.e., refreshes) the Store B/E to find new orders and automatically prints them to the Docket Printer with no human intervention.

Will this work? Who knows – as mentioned previously, a proof-of-concept is needed to determine the feasibility.

Version 4: Docket Printer integration

Robustness and Fault Tolerance

The critical part of most retail systems is that which connects directly to the revenue stream of the company. In this context, we must always provide a way for customers to order (and therefore pay), even if everything downstream of that process is held together with duct tape. In our solution diagrams, the systems/components on this critical path are:

• Customer front-end (React app served from S3)
• Customer back-end (Node JS Lambda functions behind API Gateway
• Payment Gateway (external hosted SaaS)
• Store back-end (Node JS Lambda functions behind API Gateway)
• Store database (S3 bucket)

Looking at these components, I’m happy (for now) with the inherent levels of availability of the underlying infrastructure. All the AWS services being used will elastically scale and are available in multiple Availability Zones. The Payment Gateway by it’s very nature will have (presumably) sufficient SLAs and tend to make availability a #1 concern in order to attract/maintain customers: unreliable payment gateways tend not to last very long in the market.

All that said, we should at least consider these potential failures that lie along the critical ordering path:

#	Failure	Impact	Mitigation
1	Customer front-end -> Payment Gateway	Customer cannot provide payment details	Error page displayed to customer. Retry request to Payment Gateway. Create alerts on repeated failures. Confirm with customer in store payment option.
2	Payment Gateway -> Customer back-end	System has no receipt of payment -> no sandwich made for Customer	Error page displayed to customer. Confirm with customer in store payment option.
3	Customer front-end -> Customer back-end	???	Retry request. Create alerts on repeated failures.
4	Customer back-end -> Order back-end	No record of order is recorded -> no sandwich made for Customer	Retry request. Create alerts on repeated failures.
5	Order back-end -> Order database	No record of order is recorded -> no sandwich made for Customer	Retry request. Create alerts on repeated failures.
6	Docket Printer front-end -> Store back-end	Order is not printed -> no sandwich made for Customer	Retry request. Create alerts on repeated failures.
7	Docker Printer front-end unavailable	Order is not printed -> no sandwich made for Customer	Store back-end monitors polling of Docker Printer front-ends and alerts Cashier to possible offline front-end.

Table 1: List of key failure scenarios in payment chain

Of all these mitigation approaches, many are realised by using good distributed engineering 101, as detailed in the excellent Michael Nygard book “Release It”, but I’d still like to show some of the alerting components in the next version of the container diagram (see below).

Version 5: Alerting subsystem

I haven’t shown the full set of integration points to the Alerting subsystem because it would quickly make the diagram unreadable, but it does show all the ones on the critical ordering path and also shows the path back to the cashier via an SMS triggered from the AWS Simple Notification Service.

Why SMS, I hear you ask? Because I imagine the cashier is not going to be spending much time looking at a browser, so I wanted to make sure critical, time-sensitive alerts were being brought to their attention immediately.

Next Steps

More than any of these articles, I’ve progressively built out the container diagram and tried to document my decision points along that journey. You may end up with a very different topology for your solution based on your own experience and preferences, but hopefully my thought process was at least logical.

I could continue to iterate on this diagram, bringing more focus to various parts of functional and cross-functional requirements, but we’ve done enough to show how much depth you could get to on any of these kata exercises.

Finally, there are two particular approaches to using kata which place a far higher premium on time and naturally result in considerably less mature solutions; kata workshops and using kata as a recruiting tool. I’ll look at each of these in turn in the next article.

Thanks for your patience 🙂

Did you find this article useful/interesting?

⭐

Rating: 1 out of 5.

Learning with Architecture Kata: Solution Context

Tags

architecture, architecture groups, c4, kata, recruitment process, software, software architecture, solution design, ThoughtWorks

We’ve finally done enough poking around this kata to use the C4 model to create some architecture diagrams – first up is the top-level Context Diagram…

Background

This is part of a series of articles about how I use Architecture Kata as a capability building exercise and a recruitment tool at ThoughtWorks.

Here are the previous articles in the series:

• Introduction
• Roles
• Responsibilities
• Business Processes
• Assumptions

All these articles will be focused on the same kata; “I’ll Have the BLT“. I’ve chosen this one because it’s in a domain (retail and food ordering/delivery) that most people have some innate understanding of, from either a consumer and/or employee perspective.

The C4 Model Context Diagram

I have no strong sense of loyalty to the C4 model for these diagrams, but it seems like a popular and pragmatic approach to producing consistent visual descriptions of software. If I’m working on a whiteboard, my default diagram style is everyone’s favourite, the Box And Line Diagram (BALD), but given I have time and software available for these articles, I’m using a C4 extension for VS Code to generate the C4 diagrams from text.

Given we’ve spent time identifying the roles/actors relevant to our system and also created some sequence diagrams showing much of the interaction between these roles, there is very little mental effort required to create the initial C4 Context Diagram (see below).

Even though this diagram is a bit of a mess (this was the best layout option I could use), it does highlight some aspects of my thinking that hadn’t been obvious up until now:

• There is only direct interaction between the system and the (a) Marketing, (b) Customer and (c) Cashier roles. I’ll remove the other human actors in the next version of the diagram.
• Marketing then becomes the only relevant actor within the Parent Company scope… I suspect this will result in separation of components required for promotions and those with more in-store usage in the next diagram.
• Some of the internals within the Store boundary would typically not appear in the Context diagram if we hadn’t gone through the trouble of thinking about the business processes in previous articles. This leaves the Context diagram a little more cluttered than usual.

Which leads to the next version (see below). These changes produce a more typical Context diagram.

Ideally, I would have a diagram with the System larger and more central, but I think it’s sufficient for now.

Public Service Announcement

At this point, I need to unburden myself of something that’s been on my mind since I started this series:

Architecture diagrams are not the same as architecture

Architecture diagrams are perspectives on architecture. The real architecture is only truly present in the actual implementation of the system (i.e., the code itself). In the same way, even if the Sydney Opera House was designed to be a boxy, utilitarian bunker, the true architecture is still the sail-shaped reality with which we’re all familiar.

Architectural plan versus reality

All we are doing by creating these diagrams is producing low-investment representations of what the architecture might actually be.

Next Steps

With our C4 Context diagram behind us, the next article will see us diving deeper into the implementation of our solution via a Container diagram.

Did you find this article useful/interesting?

⭐

Rating: 1 out of 5.

Learning with Architecture Kata: Assumptions

Tags

architecture, architecture groups, c4, kata, recruitment process, software, software architecture, solution design, ThoughtWorks

Just before we dive into architecture diagrams for our kata, I want to take a little time to look at the types of information you find in most kata descriptions

Background

This is part of a series of articles about how I use Architecture Kata as a capability building exercise and a recruitment tool at ThoughtWorks.

Here are the previous articles in the series:

• Introduction
• Roles
• Responsibilities
• Business Processes

All these articles will be focused on the same kata; “I’ll Have the BLT“. I’ve chosen this one because it’s in a domain (retail and food ordering/delivery) that most people have some innate understanding of, from either a consumer and/or employee perspective.

Inside the Kata description

Depending on how much you want to “get into character” as you work through a kata, there are usually a number of leads in each description, just like in any good detective story. Some of these leads might end up in dead ends, which neither deepen your understanding of the problem nor impact the architectural solution. However, others might suggest nuance and detail which help guide your hand when making the inevitable trade-offs that separate capable architects from the rest.

This article tries to find and pull on some of these background threads. I’m going to ask a lot of questions but answer very few of them. I’ll leave you, dear reader, to resolve these questions in a way that allows you to maintain a consistent context for your solution.

These are the key threads I’ve tended to think about when looking at the BLT kata over the years…

“national sandwich shop”

The food retail industry contains businesses that live-or-die on a high volume/low margin business model. Staff tend to be relatively lowly paid, but salaries will still be the biggest components of the businesses operational expenditure. Given food wastes quickly, stock control is critical to maximizing yield (i.e., making the best use of the stock with minimal waste) and keeping costs down. Such price conscious businesses will not have the ability to incur massive IT costs for new systems which suggests subscription-based IT services to amortise costs across a wider period.

Because sandwiches tend to consumed primarily at lunchtime (by the Australian definition and consumption of “sandwich” at least), this suggests opening hours are limited (business hours only?) and high availability might not be a key cross-functional requirement for in-store components of the solution.

‘fax in your order’

Possibly a red-herring, but could also speak to relatively low technical literacy (and maturity of IT systems) within the business. This would impact the design of system errors, fault tolerance and recovery, especially for the in-store components.

Why?

Understanding the key business drivers behind a system is critical to making appropriate trade-off decisions in architecture. What is driving the customer to this solution?

• Can they see their customer base moving to competitors because they don’t support online ordering?
• Is this part of a strategic uplift of the organisation in advance of expanding overseas, or possibly being purchased?
• Are services like UberEats disintermediating their market?
• If they do actually rely on physical faxes in stores, are there current or future hardware cost/support/availability issues?
• Will having an online solution lead to a better ability to understand their customers and therefore provide more tailored solutions?

Depending on how you answer and weigh these questions could have a significant impact on your solution.

“current fax-in service”

We’ve already considered this phrase to some degree in our business processes by assuming the existence of a Docket Printer in each store, but we should also think of what other current IT services we might need to consider and possibly integrate with. You could assume there wont be many such systems in stores (given the reliance on fax), but – if we hadn’t de-scoped Stock Management from our solution previously – we could have some significant integration requirements within the parent company IT infrastructure.

“Users: thousands, perhaps one day millions”

This statement is almost completely unhelpful without providing some more specific predictions such as orders/day, sandwiches/order or concurrent orders, but there’s nothing in this statement that suggests throughput or data storage volumes will be anything significant in the final solution. Even the caveat of “perhaps one day millions” sounds like the wishful thinking of a company executive and shouldn’t constrain our architectural thinking at this time.

“be given a time to pick up their sandwich”

This is a possible rabbit hole of a requirement. At the simplest level, you could hard-code a fixed period to prepare the sandwich, possibly with an increased delay for known peak periods. At the other end of the complexity spectrum, the System could be provided with current data around the throughput of the store based on number of incoming orders (online, fax and presumably walk-ups), and provide the Customer with a highly accurate estimate of the pickup time.

Because of the additional integration complexity around the latter solution, this would be a requirement I would strongly argue is not worth the time to implement, at least in the initial version of the solution.

“integrate with several external mapping services”

Hmmm, what do we make of this? Firstly, it suggests our Customer is using a mobile platform to navigate their way towards the shop, but given there’s no other mobile-specific requirement for customers, I’d err on interpreting this requirement to mean “we’ll add a link to the store address that you can use to navigate to Google Maps, or your relevant GIS provider.

This does lead to a consideration around the ordering process… does the Customer choose their store explicitly when they order, or do they order and provide their address, and then the order is routed to the appropriate store?

“if the shop offers a delivery service”

I’ve seen so many teams spend a disproportionate amount of time solving the delivery service integration… which is not even provided at each store! It would be nice to know what percentage of stores have a delivery service and how dynamic this number is to help understand how significant these requirements are. Is the company tending towards more delivery services in stores, or are they a holdover from a previous version of the business and being phased out?

“Sandwich shops are franchised, each with a different owner.”

If you understand how franchise models operate in retail (and I have enough knowledge to be dangerous), then there are significant architectural implications behind this statement. Franchise owners generally have very little choice over how their store operates; pricing, stock, menu, etc are all usually contractually owned and operated by the parent company. Similarly, IT infrastructure is usually a parent company responsibility.

What is less clear to me is who owns customer data if we build a solution that has the ability to create a strong sense of customer identity. If our solution eventually provides customer accounts and tracks customer order history, loyalty schemes and other customer-based promotions, then how is this data safely and securely stored, both away from the prying eyes of the general public, but also from other franchisees, who are effectively competing with each other for the same customer base?

“near-future plans to expand overseas”

With my architecture hat on, I’m loathe to ignore requirements that suggest a solution requiring internationalisation, but I’m even more reluctant to bake these assumptions into the initial solution which has yet to be built, let alone proven successful.

Operating in different markets implies:

• support for different currencies
• very likely different tax calculations
• integration to different Payment Gateway solutions
• local menu variations (either due to stock variations or customer demand)
• local promotion variations
• local visual design standards/expectations
• possible extended character sets needed for text display and even layout (e.g., right-to-left rendering)
• regional hosting restrictions (e.g., data sovereignty and specific laws like GDPR)

With such a large number of variations across so many significant architectural axes, I’m tempted to file this requirement in the “we’ll cross that bridge when we come to it” bucket and rely on general good design/abstraction practices to leave the initial solution open to future evolution.

“Corporate goal is to hire inexpensive labour to maximize profit.”

Somewhere in my kata journey, I can across the term Architecturally Significant Requirement… this is not one of those. I cannot imagine how I would approach this solution differently irrespective of the existence of this statement. You could argue that ease-of-use needs are highlighted by this statement, but I don’t think there’s anything compelling here to elevate those requirements above what you would normally do for any other retail food business.

If I’m being picky, it doesn’t sound like a corporate goal either 🙂

Next Steps

So we’ve trawled through the kata description and found a number of red herrings and statements that appeared significant on the surface but ended up being too vague to be helpful. We also found some more useful clues to the context for the solution and added a number of extra unanswered questions we’ll need to consider in subsequent articles.

The next article will use the C4 diagram model to define a high level view of the implementation of the System.

Did you find this article useful/interesting?

⭐

Rating: 1 out of 5.

Learning with Architecture Kata: Business Processes

Tags

architecture, architecture groups, c4, kata, recruitment process, software, software architecture, solution design, ThoughtWorks

Systems exist to enable, optimise or support business processes. So far with our kata, we have created isolated sets of responsibilities for our roles/actors, but there’s nothing to piece them together into these valuable processes… yet.

Background

This is part of a series of articles about how I use Architecture Kata as a capability building exercise and a recruitment tool at ThoughtWorks.

Here are the previous articles in the series:

• Introduction
• Roles
• Responsibilities

All these articles will be focused on the same kata; “I’ll Have the BLT”. See below for the description for this kata. I’ve chosen this one because it’s in a domain (retail and food ordering/delivery) that most people have some innate understanding of, from either a consumer and/or employee perspective.

http://nealford.com/katas/kata?id=BLT

From responsibilities to business processes

Below are the responsibilities we created in the previous exercise…

Role	Responsibility	Notes
Customer	– Place order with Cashier – Pay for order to Cashier – Travel to store	– Customer identity via order # only – No change to payment systems
Cashier	– Accept order from Customer – Accept payment from Customer – Print order for Customer	– No change to current in-store ordering process
Sandwich Hand	– Receive order from Cashier – Prepare sandwich – Handover sandwich to Cashier	– No change to current in-store ordering process
Driver	– Pickup order from Cashier – Deliver order to Customer – Accept payment from Customer	– Works only for single Franchise Owner – Cash only payments from Customer upon delivery
Franchise Owner	– Manage local promotions/specials – Manage Driver(s) (if any)	– Stock management out-of-scope
Marketing	– Manage national promotions/specials	– Stock management out-of-scope

Roles & responsibilities

Ordering

If you join up these responsibilities, the underlying business process flow starts to emerge. I’ve produced some UML Sequence diagrams below for the primary ordering flows for this kata (i.e., for delivery and for in-store pickup). I like sequence diagrams because they clearly show the various roles/actors involved in process, but you could also use swim-lane diagrams, which have a similar focus but opposite orientation.

Note: there are a few new actors in these diagrams that we haven’t spoken of previously:

• System – a very unimaginative name for the solution we’ll be building. Will this be implemented as a single application, or multiple ones? We don’t know yet – those decisions will be made later.
• Docket Printer – this is part of the existing IT infrastructure I’ve assumed exists at all stores. This docket printer is connected to the current PoS (Point of Sale) hardware and prints the order details which become the physical copy of the order for the Sandwich Maker.
• Payment Gateway – a 3rd party hosted solution allowing customers to make online payments using credit cards and notify the store of a successful payment. I’ve shown its use only for a single process below, but it applies to both ordering processes.

Promotions

What about the business processes for the local and national promotions responsibilities we identified? Well, they certainly need to be supported by our solution, but I’m going to leave them out of scope for now. In my mind, I see promotions processes being largely identical to each other and centred around only a single role (Franchise Owner and Marketing respectively) with only limited integration with the System actor in terms of displaying the menu for the Customer.

Note: If there were some very tricky or specific requirements around how promotions are done (e.g., reliant on current stock levels or a firmer notion of Customer identity or previous buying behaviour), I might do some process mapping for promotions as well.

Next Steps

Before we get to the next steps, we should ask ourselves: are there any key risks in our thinking around the solution so far?

• We haven’t described how the new System will integrate with the existing PoS systems. Do we now have two records of orders for a single store, depending on whether the order originated online or in-store? Or will the Docket Printer serve as the authoritative source of truth?
• For customers wanting delivery, we haven’t identified a process to allow them to pay the driver electronically… is it reasonable for the driver to only accept cash on delivery?
• If our Docket Printer fails to print the order, how will this situation be detected. Can the Docket Printer send a signal to the System? How will the Cashier be alerted to this situation? As a general note, the processes I’ve drawn show the happy path only.

Let’s sleep on these questions for now and see whether we have good answers for them by the end of the kata.

The next article will use the C4 diagram model to define a high level view of the implementation of the System. We’ll be making some more assumptions around the nature of the business we’re building this system for to confidently trade-off between various architectural qualities in our solution.

Did you find this article useful/interesting?

⭐

Rating: 1 out of 5.

Learning with Architecture Kata: Responsibilities

Tags

architecture, architecture groups, c4, kata, recruitment process, software, software architecture, solution design, ThoughtWorks

Each role you’ve identified from your kata description should have a set of responsibilities associated with it. Identifying these responsibilities will be the basis of the requirements driving the solution.

Background

This is part of a series of articles about how I use Architecture Kata as a capability building exercise and a recruitment tool at ThoughtWorks.

Here are the previous articles in the series:

• Introduction
• Roles

All these articles will be focused on the same kata; “I’ll Have the BLT”. See below for the description for this kata. I’ve chosen this one because it’s in a domain (retail and food ordering/delivery) that most people have some innate understanding of, from either a consumer and/or employee perspective.

http://nealford.com/katas/kata?id=BLT

The Role/Responsibility relationship

In the last article, we landed on this set of roles in the system:

• Customer User
• Driver
• Franchise Owner (also responsible for local promotions)
• Marketing (for national promotions)
• Cashier (for receiving in-store payment)
• Sandwich Hand (for making sandwiches)

A logical way of checking whether we’ve found all the necessary roles is to go back to the kata description and extract all the implied and assumed responsibilities for the people using the solution.

If we find responsibilities that don’t logically belong with any role (i.e., something to be done but no-one to do it), maybe we’ve missed a role that needs to be added.

If we have a role we cannot associate any responsibility with (i.e., someone who exists but with nothing to do), maybe we’ve found a role that actually doesn’t have any interaction with the system at all.

Identifying Responsibilities

How you go about identifying responsibilities is largely up to you. I’ve captured my thoughts in the table below. It’s typical at this point to start making more assumptions about how the proposed solution will work. These assumptions provide some context/boundaries for these responsibilities.

Let’s look at the responsibilities and then I’ll talk about the assumptions.

Role	Responsibility	Notes
Customer	– Place order with Cashier – Pay for order to Cashier – Travel to store	– Customer identity via order # only – No change to payment systems
Cashier	– Accept order from Customer – Accept payment from Customer – Print order for Customer	– No change to current in-store ordering process
Sandwich Hand	– Receive order from Cashier – Prepare sandwich – Handover sandwich to Cashier	– No change to current in-store ordering process
Driver	– Pickup order from Cashier – Deliver order to Customer – Accept payment from Customer	– Works only for single Franchise Owner – Cash only payments from Customer upon delivery
Franchise Owner	– Manage local promotions/specials – Manage Driver(s) (if any)	– Stock management out-of-scope
Marketing	– Manage national promotions/specials	– Stock management out-of-scope

Roles & responsibilities

One BIG assumption I’ve made here is de-scoping stock management. Stock management is an entire business domain in itself, so I’m partially motivated by laziness and simplicity but also because it seems tangential to the core of the kata. With a large enough chain of sandwich shops (think Subway), stock management would likely be integrated into promotions (e.g., specials on sandwiches using ingredients that are need to be moved quickly).

A secondary key assumption regards no permanent notion of customer identity. The customer is identified only via their order number. Therefore, there is no need for the customer to create an account and login, which helpfully removes the need for lots of administrative functionality around user management (e.g., password resets, forgotten passwords, etc). This assumption relies on the existing payment infrastructure being able to handle an anonymous payment, which seems like a reasonable expectation.

Hopefully you would come up with a similar set of responsibilities for this kata as well. As I mentioned before, I suspect most of us have physically ordered food for in-store collection or delivery, so there shouldn’t be anything too foreign about this – not all kata are as broadly approachable however.

Next Steps

These roles reference each other quite heavily, but we don’t have a good sense of the natural business processes that the system supports. My table of responsibilities don’t talk about the order of these activities or how the responsibilities interrelate. In fact, my table doesn’t even recognize the existence of a System role, which handles much of the intermediary responsibilities between the human roles. This gap will be covered in the next article where we identify key business processes that the solution needs to support.

Did you find this article useful/interesting?

⭐

Rating: 1 out of 5.

Learning with Architecture Kata: Roles

Tags

architecture, architecture groups, c4, kata, software, software architecture, solution design, ThoughtWorks

A nice launch into the world of Architecture Kata is identifying the roles interacting with the solution. Sometimes these roles will be obvious. Sometimes they’re hidden within the description and take some digging to discover.

Background

This is part of a series of articles about how I use Architecture Kata as a capability building exercise and a recruitment tool at ThoughtWorks.

Here are the previous articles in the series:

• Introduction

All these articles will be focused on the same kata; “I’ll Have the BLT”. See below for the description for this kata. I’ve chosen this one because it’s in a domain (retail and food ordering/delivery) that most people have some innate understanding of, from either a consumer and/or employee perspective.

http://nealford.com/katas/kata?id=BLT

Note: If this is the first time you’ve looked at a kata description in detail, you will have as many questions as answers. This is deliberate: these kata are not intended to be exhaustively detailed requirements. They are merely brief descriptions of a problem. And without a human to add more context to the problem, you’ll need to make lots of assumptions to fill out the missing pieces of the puzzle.

Identifying Roles

The first step in our journey is to find the user or system roles implied by the problem description.

So what are the roles that immediately jump out from the description?

• User
• Driver
• Franchise owner

Is that all? No, there’s a couple of issues with this initial list:

Firstly, let’s talk about Customer as a more specific form of User, because there are invariably other users of the system apart from those who are the people buying sandwiches.

It also occurs to me that the person placing the order need not be the same person physically picking up or receiving the delivery (i.e., separate Sandwich Orderer and Sandwich Recipient roles). This distinction may not be relevant in the long term, so we’ll just store this in the back of our mind for now.

Reading between the lines, there are a few other human roles as well: the promotions are at national and local level and given the franchise model, that implies separate roles to create these offers. We’ll work on good names for these roles soon.

Looking at the in-store customer interactions, there are roles required to receive payments from the Customer and actually make the sandwiches. Very likely this roles are shared across the same people, but let’s keep them separate for now.

So the second version of our roles looks like:

• Customer User
• Driver
• Franchise Owner (also responsible for local promotions)
• Marketing (for national promotions)
• Cashier (for receiving in-store payment)
• Sandwich Hand (for making sandwiches)

Next Steps

In the next article, we’ll identify the specific responsibilities for each of these roles. We also want to be open to discovering more roles as we go through the subsequent steps. Our current list is a good start, but – as our understanding deepens and we concentrate on more detailed business processes – we might spot some roles we missed on this first pass.

These roles will also make an appearance on our architecture diagrams. I’ll be using the C4 model where roles are shown on Level 1 Context diagrams.

Did you find this article useful/interesting?

⭐

Rating: 1 out of 5.

Learning with Architecture Kata: Introduction

Tags

architecture, architecture groups, c4, kata, recruitment, software, software arch, solution design, ThoughtWorks

Background

Over the last several years, I’ve used Architecture Kata regularly as the basis for both a group workshop exercise and a recruitment tool.  I’ve completed lots of these exercises as both participant and facilitator and have developed a good sense of how to use these kata and where the dragons lie.

This is the first of a series of articles about how I use kata to build and/or identify solution design skills with colleagues and candidates at ThoughtWorks.

Enjoy!

Audience

These articles are written for experienced software engineers who are required to create solution designs as part of their role.

I believe Architecture to be a capability rather than a role or title, so you do not need to be officially called an “Architect” to benefit from this material.

These articles don’t assume any specific domain or technical knowledge, although the later episodes do present a solution design for a distributed web application to be hosted on Amazon Web Services. Having conceptual knowledge of this type of solution and AWS would be beneficial, but not mandatory.

Architecture Kata

Ted Neward – the creator of Architecture Katas – sums up the problem they address perfectly with this quote:

So how are we supposed to get great architects, if
they only get the chance to architect fewer than
a half-dozen times in their career?

Ted Neward

In less succinct words, the opportunity to architect a “live” software system is too infrequent and too risky a process to be the sole mechanism by which architects hone this skill.  Architecture Kata were created to provide samples of realistic high level problems to solve, much like other uses of the term “kata” in the software industry.

All forms of kata endeavour to provide a safe way to focus on particular aspects of your craft.  For example, with a code kata you might repeatedly solve the same list processing problem via:

• a variety of looping forms (e.g., for, while, until, etc)
• recursion
• a higher order list comprehension (e.g., map).

There is no commercial or schedule risk to any of these solutions. Kata is used purely as a learning task – a set of rehearsals away from the spotlight and heightened expectations of real life software development.

Similarly, you can use architectural kata with a deliberate focus on specific architectural forms:

1. start with a monolithic implementation
2. iterate towards a finer grained microservices solution
3. switch your integration approach from synchronous and RESTful to asynchronous and event-based. 
4. change focus to specific non-functional requirements (e.g., security, availability, scale etc)

Each of these decision points will have a material impact on your architecture.

If you’ve got this far reading and haven’t had a look at any of the kata, I’d advise you to go ahead and do so now for context.  I’ll wait…

The Process

There are many ways to skin an architecture kat-a :-), but I follow the following process when introducing people to them:

Stage	Focus
Roles	what are the the primary roles interacting with the solution?
Responsibilities	what are the key responsibilities for each of these roles?
Capabilities	what are the core business capabilities required of the solution?
Business Process	what business processes does the system need to support?
Logical Architecture	what are the high level components of the technical solution?
Physical/Deployment Architecture	how are those high level components implemented?

The steps to solve an Architecture Kata

Next Steps

The following articles in this series will decompose each of these steps via a worked example of the I’ll Have The BLT kata.

Did you find this article useful/interesting?

⭐

Rating: 1 out of 5.

Clojure as First Language

Tags

clojure, development, learning, programming

At the time of writing, I’m organising a ClojureBridge workshop.  ClojureBridge targets underrepresented groups who are either brand new to programming or only have limited experience.  While preparing for the workshop, I struggled to find quality info in the public domain about whether Clojure is a suitable first programming language.  There are lots of introductions to Clojure written from the assumption that the reader/viewer has previous programming experience, but very little substance around choosing Clojure (or any other language for that matter) as your first language.  So this is my attempt to answer the question:

“Is Clojure a good choice as a first programming language?”

Criteria

The get-out-of-jail answer to any question like this is “it depends”, so I’m going to list some key criteria that I think are important for someone choosing their first programming language, even if the significance of some of these criteria might not be immediately apparent.  The criteria I settled on are:

1. TTHW (Time To Hello World)
2. Community Support
3. Funability
4. Industry relevance

I’ll step through each of these criteria and give a subjective “grade” (i.e., “A” through to “F”)  on how well Clojure meets these criteria, as well has listing other language choices that perform particularly well or poorly on each criteria.

1. TTHW (Time To Hello World)

There is an age-old tradition where programs that show the text “Hello World” on the screen are the first ones you see/construct in any new language.  The essence of “Hello World” programs is that they are simple, quick to write and with very little that can go wrong with them.  “Hello World” programs also provide unambiguous tangible feedback that they are working (or not).  This criteria recognises how important it is for a first language to support novice developers by allowing them to write and run programs as quickly as possible.

With the only prerequisite that you have a computer with a working internet connection and browser, languages that perform well on this criteria allow you to code without the need to install or configure any additional software.  On the other end of the spectrum are languages which require installation and configuration of significant amounts of non-standard software.

Hello World in the Browser

TryClojure, 4Clojure and Repl.it are three online Clojure environments (amongst others) that let you use only your browser to experiment with the Clojure language.  It’s important to note that while these tools are great for the early days of experimenting with a language, you will fairly quickly want/need to write code on your own machine which requires the installation of additional software, and Clojure does have a higher hurdle to clear than some other languages in this respect.

Clojure Grade: A (lots of options, very little friction)

Hello World on your Computer

Clojure runs on top of the Java programming language.  Learning Clojure doesn’t require you to learn Java, but Java must be installed.  Many operating systems (e.g., Windows, OSX on Apple computers) come with a version of Java pre-installed, but in some cases Java wont be installed or be the wrong version for Clojure, so installing Java will be required as well.

Once Java is installed, installing Clojure usually requires that you install Leiningen (another piece of software you use to construct Clojure programs) which will allow you to download and install Clojure easily.  Installing Leiningen requires some familiarity with the command line tools on your Operating System, which can complicate things if you have not used these tools before.

A final step in this process is to install some form of text editor or IDE to write your Clojure programs.  Your computer will come installed with a basic editor already, but it will not be especially useful for Clojure programming in it’s default state so options like Sublime Text, Atom or Cursive are popular choices to quickly provide a beginner developer a decent development environment.

Clojure Grade: C (compared to languages like Ruby and Python which are often pre-installed on most Apple and Linux computers).

2. Support

This criteria could have been renamed “Time to First StackOverflow Answer” as it relates to how much support the language community will/can provide to beginner developers.  This support could come from a variety of channels; official documentation, tool support, online communities like StackOverflow, local user groups, conferences, books, etc.

From a beginner’s perspective, it’s important to understand that languages come with their own unique culture which often flows from their creators and high profile advocates.  My experience been that community support peaks in the early years of a language’s popularity where the “size” of the language is small enough to keep the active members of the community cohesive and passionate about it’s growth.  As languages mature and their reach into the software development world both broadens and slows, the pioneering spirit of the community will most likely dissipate as the need to support programmers of various levels of experience exceeds the ability/desire of the core community.  The upside of this phase of a language’s evolution is that all the beginner problems have been solved many, many times over and Google will answer the vast majority of your questions fairly effectively.

Clojure is a relatively mature language that is attracting the “Early Majority” in the adoption life cycle.  That said, Clojure is a language from the functional programming family of languages and the mathematical and academic background to this group can flow into the online and physical communities (e.g., user groups, conferences) which can portray Clojure as less accessible than necessary.

Clojure Grade: B- (minus marks for some of the pious FP attitude that leaks from the community)

3. Funability

Of all the largely subjective nature of these criteria, this one takes the cake!  How does one measure how much fun it is to program in a language?  But for a beginner programmer, using your first language must generate positive vibes or you’ll quickly lose interest.

Under the premise that a sense of achievement (i.e., accomplishing what I set out to do) will generate feelings of satisfaction, I’m going to use a proxy metric of “how much does the language get in my way of doing what I want” to measure how much fun Clojure is, and I think Clojure has a good story to tell in this sense:

(Note: some of what follows is might not be immediately obvious/understandable to completely novice developers)

• Dynamic typing – not needing to worry (much) about types increases the speed with which beginner programmers can produce working code.
• The REPL – having an interactive environment to experiment in not only overcomes the downside of Clojure’s Java dependence but provides instantaneous feedback for a development cohort that have no past experience to give them confidence in their actions.
• Concise syntax – less syntactic breadth means less mental energy needed when coding.  There’s still the APIs to grok, but almost everything in Clojure code is a function call with a very small set of reserved terms in the language.

And on the negative side…

• Java/Clojure Stacktraces – it wont be long before every new Clojure developer is presented with their first stacktrace… and even as a seasoned Java developer, I still recoil at the sight of some of these.
• Prefix notation – this might be a vastly polarising topic, but I suspect a group of people will never get comfortable with prefix notation and the sea of parenthesis that are so commonly associated with Clojure and it’s siblings in the Lisp family.

Clojure Grade: B- (with Ruby as possibly the most “fun” language I’m aware of with all the benefits of dynamic typing and a REPL, but without the pain of reading Clojure-like stacktraces and a more “natural” infix notation).

4. Industry relevance

Of course, many people start coding as part of a career change, so choosing a first language that puts you somewhere along a path to said career might factor very highly in importance.  Breaking into the software development market with your only experience being in “niche isolated language X” is probably not going to stand out on your fledgling CV as “highly popular, widely used language Y”.

It’s hard to deny that the “best” language if you wish to optimise for (broard) industry relevance above everything else is JavaScript.  Ubiquitous on the browser and with considerable popularity on the server via Node.js, Javascript (considerable warts and all) is the ideal choice if you want to bootstrap yourself into a development career as quickly as possible.

Clojure has nowhere near the market presence as Javascript (or Ruby or Python for that matter), but it does have success stories at some fairly high profile brands.  It also has a browser version of the language – ClojureScript – which can give you exposure to front-end web development with little extra investment.

However the biggest advantage Clojure has in industry relevance is the Java connection.  Java is an very mature and widely adopted language that is deeply integrated into the IT systems of tens of thousands of companies.  The JVM (platform on which both Java and Clojure run) will be a permanent part of the global IT landscape for decades to come, and more and more companies with existing experience in the JVM (via Java) are looking to broaden this experience with other JVM languages (like Clojure).

Clojure Grade: B (Javascript is an A+ on this scale.  Clojure looses marks for relative lack of popularity, but gains some back via ClojureScript and the Java connection.)

Conclusion

“Is Clojure a good choice as a first programming language?”

Coming back to the criteria, I judged Clojure as follows:

• Time To Hello World – A (on browser) and C (on computer)
• Community Support – B minus
• Funability – B minus
• Industry relevance – B

Overall, that’s not a bad report card and while Clojure doesn’t stack up as the obvious choice for a first programming language, it’s not a bad choice by any means.

Individuals may place different weights against these criteria, but if you keep in mind that your first programming language shouldn’t also be your last one (i.e., you can/should learn plenty more over time), there’s very little downside to making Clojure the first one.

Clojure gives you a good first programming experience with little overhead, lots of support avenues and good options to turn your programming hobby into the beginnings of a programming career.

5 things you’ll do as a graduate developer

Background

Universities don’t have the time or scale to give undergraduate software engineering students a complete sense of what it’s like to work in industry, which means there can be some eye opening moments for many graduates once they leave tertiary education and become an IT professional.  I’ve prepared a list below containing some of the big ticket items that might surprise many a graduate upon entering the industry, but will be commonplace to seasoned engineers.

This list is not meant to be definitive or exhaustive, but it does capture key moments that many graduate developers will go through, depending on where they land their first development job.

So here’s the list:

1. Release code you aren’t proud of

2. Not coding

3. Work with someone more experienced than yourself

4. Work to someone else’s deadline

5. Work long hours

For each item, I’ve included examples of (likely?) reactions from graduates, trying to cover both ends of the spectrum of reasonableness.  I’ve also included links to seminal text books which provide a lot of extra knowledge around the item in case anyone reads anymore.

1. Release code you aren’t proud of

Firstly, a basic home truth: given enough time, 100% of your code will become something you no longer take pride in 😦 With time comes experience, (hopefully) skill and exposure to alternate ways to write code and all these changes mean you look back at the code you’ve written and see how differently you would write it now.  In extreme cases, you struggle to even associate any of your old code with how you see yourself as a developer now.

But it’s not the above situation that this item is about – it’s when you release code that you know at the time is not your best work, but external factors prevent you from fixing/improving the code.  The typical scenario is project deadlines forcing you to move onto the next piece of work as soon as you have the most basic working version of a solution to your current piece of work.

Good Reaction

Even as a graduate developer, you’ll be starting to build a spidey sense that tells you whether the code you’ve written is ugly-but-perfectly-workable versus ugly-and-potentially-buggy.  Where the code falls on this spectrum should dictate how much energy you use to push back against the forces preventing you from working further on the code.  It also helps to have an estimate of how much time you need to bring the code up to a level you believe is truly production-ready.  Sense checking this feeling with a more experienced developer is critical at this point, lest you are being overly optimistic or pessimistic with your estimate.

The other side of the equation is understanding just what is behind the opposing forces: How tight is the deadline?  Are the consequences of missing the deadline too high?  Is the importance of your code high or low relative to these forces?

Poor Reaction #1

Say nothing, do nothing.  Accept this as a fact of life and move on.

Poor Reaction #2

Use only your own counsel to gauge whether your code is ready for release.  Refuse to budge even an inch until you have achieved code which meets your standards.

Further Reading

Refactoring (Martin Fowler) – For theory and practical advice on how to incrementally improve the quality of the code you’ve written

2. Not Coding

“Not coding” can mean lots of things, but it will most likely be related tasks like testing, writing documentation or working with customer support or operations teams.  You will be often be assigned these activities as part of a larger on-boarding process, and the rationale is usually along the lines of:

• Increasing your level of knowledge around the business environment in which the code runs
• Giving you a softer introduction to your role than throwing you in the deep end immediately
• Buying some time during a critical activity for other people to become free to support you

Good Reaction

If you’re not coding in the early stages of your career, it is key to understand the reasons for this (hopefully they align with the above) and how long this stage will last.  Make the most of the information you collect during this stage and the people you’ll meet.  Use all this context when you finally sit down to solve their problems.

Poor Reaction

“I’m a coder.  I code.  Testers test.  Technical writers write.  And ne’er the twain shall meet.”

Further Reading

The Pragmatic Programmer (Andy Hunt and Dave Thomas) – so many gems of wisdom for programmers of all ages, but includes general career advice as well

3. Work with someone more experienced than yourself

This can come in several forms; some companies have explicit mentor arrangement for junior developers, in other cases, it could be the natural side effect of coming into a team with more experienced developers, or it could be a more disciplined team culture of pair programming that finds you spending a lot of time developing with senior engineers.

Good Reaction

Whether this is a deliberate master/apprentice coupling or just opportunistic, there are so many benefits to working in this scenario.  Senior developers understand the business domain, codebase and technical stack far better than you and will know where the gotchas lie.  They will know the architectural and design patterns intuitively: things that can take a long time to sink in.  They will also (likely) know the key people around the work which will make navigating the informal communication channels far easier.

Having access to a good mentor(s) can have a significant impact on how quickly a graduate developer picks up speed in their career.  Having an open mind and a willingness to listen is vital.  Be careful not to blindly accept everything you hear/see though – working with more experienced people doesn’t mean you turn your brain off and take no responsibility for the work being done.  Good mentors should welcome questions from enthusiastic junior devs.

Poor Reaction

“I’ve got this – hold my beer (after all, I did get great grades in my software subjects at university/college).”

Further Reading

Pair Programming Illuminated (Laurie Williams) – Laurie was one of the first people to do empirical studies on the effectiveness of pair programming.

4. Work to someone else’s deadline

It’s very, very rare (i.e., unicorn rare) to find a development project with completely elastic deadlines.  Deadlines are derived from pressures; market pressures (e.g., what is the market demanding, what is the competition doing, when is the next big event we’re targeting), budget pressures (e.g., we have to get this done for less than $X), timeline pressures (e.g., end of financial/tax year, in time for the System X upgrade in Q3).

Whatever the pressures are, some poor sucker derives a schedule that will clearly show that the work will get done by the required deadline and then the starter’s gun fires: it’s now down to your team to make the plan a reality (note: massive oversimplification here).  And whatever the pressures are, the presence of a deadline and our general inability to predict what course a development project will follow inevitably means time allocated to work will fall short of the time needed to do the work… and how people react to this reality is often the difference between success and failure, at a individual level, team level and so on up to the overall success (or failure) of the program or even organisation.

Good Reaction

“Is there anything I can see in the work I’m doing that could be done simpler, cheaper, quicker?  Is all the functionality needed for day 1, or can some wait until a later release?  Am I spinning my wheels by struggling to finish my work solo for the benefit of my own knowledge, or am I asking for help regularly, even if it means I don’t understand 100% of what I’ve done?”

Is this deadline affecting everyone involved, or is it really just the development team?

Poor Reaction

“They cannot possibly expect me to finish this work in 2 weeks! We originally estimated 6 weeks and none of the scope has changed.  And what about the 2 month delay to the start of the work?!? Why didn’t that change the deadline?  Even as a graduate, I can see the lunatics are running the asylum!!!”

Further Reading

Software Estimation (Steve McConnell) – sheds some light on the risks around estimating software and will help make you a better estimator as a consequence (p.s., you’ll still be wrong most of the time though :-))

5. Work long hours

Given the likelihood you’ll be working to a tight deadline, a lazy but very common reaction from those ultimately responsible for the delivery of the work (most likely a project or program manager) is to ask the team to work extra hours to meet the deadline.  This request could come in the form of longer days, or weekends, or a block on taking leave, or any combination of these.  For all the enlightened conversations around the IT industry, when push comes to shove, we invariably fall back to cracking the whip to meet a deadline with very little in the way of compensation for our efforts.

But unpleasant though these situations may be, it’s important for graduate developers to experience these environments at least once for there are many lessons to be learnt from these situations.

Good Reaction

Have a good understanding of how much time you’re willing to give for the cause and how critical this time of yours will be to meet the deadline.  There’s no point if you work 80 hours weeks on work that is nowhere near the critical path of a project.

My experience has shown me that short bursts of long hours can help considerably in these situations.  By “short bursts”, I mean effort measured in days and possibly weeks, but definitely not months.

Poor Reaction 1

“My contract says I work 37.5 hours a week.  I’ll see you at 9:00am tomorrow.”  To me, this is a sign that your treating this as a job rather than a career.  Being successful in any career requires you to undertake some personal investment and being completely unwilling to budge is not a path to enlightenment.

Poor Reaction 2

“What day is it?  I’ve been sitting here coding for so long I cannot really see the screen anymore, but I’m sure another 3-4 hours is all I need.   And where’s that pallet of Red Bull I ordered?”

Further Reading

Death March (Ed Yourdon) – sometimes working long hours is taken to the extreme, and these situations have a suitably

The Mythical Man Month (Fred Brooks) – this book isn’t guaranteed to help you fight the battle over long hours, but will equip you to understand how the situation may have arisen.