Developer turned Product Owner

The backlog is a mess. The order is random. There’s no grouping or coherence, let alone a vision of any kind. Stories are unclear, if at all described, and sprint planning takes forever while developers try to figure out what the product owner wants. I heard these complaints over and over again from teams, and then I had a chance to become a product owner myself. Turns out it’s not much different from a developer’s work.


Taking an agile approach means making small steps and testing how they influence the product. Just like TDD in programming:

  1. Think what you want to do.
  2. Decide how you will measure success, like you code a test.
  3. Have the team implement your idea, usually by writing code and just enough to make the test pass.
  4. Evaluate the idea against your KPIs, like you would run your test.
  5. With the findings, go back to 1 to adjust your hypothesis and approach.

Clean Code

The backlog items you’re preparing—usually stories, will be read and relied on by the team to build a product increment. The clearer the language, the easier it’ll be to understand and follow.

  • clear, unambiguous, expressive naming,
  • precise vocabulary,
  • short paragraphs,
  • good English (or any other language you use),

all of these are qualities that’ll help the team deliver faster and with fewer misinterpretations. All the same in code, where good naming for variables, functions, objects matters, and short, focused functions and components are preferred.


A good backlog is well organized, with related items grouped together into epics, aligned along a vision for the product. This in turn provides direction and focus for both the team and stakeholders, guiding conversations on how the product should be shaped, deciding what fits in and more importantly what doesn’t. It allows setting release and sprint goals, that the team can measure their progress against.

All this is exactly like abstraction in code, where similar logic gets grouped into objects, similar objects grouped into packages, named after the domain they cover. From an orderly, well-named code base one should easily be able to identify the purpose of the system, decide where to put new code and whether it belongs in there at all.

I know what the team’s doing

My programming experience is helping me tremendously in shaping the backlog and working with the team. Requirements are crisp, or quickly refactored to become so, order is clear and it’s easy to see what fits into our current vision and what should be deferred.

On top of that, I know the work the team does. When they come back reporting issues with implementing certain items, I understand those and we can easily adjust plans to reality, with the new information we received. Everyone’s work becomes easier and we’re steadily moving forward.

Obviously not every developer would make a good product owner. There’s a lot of touchy-feely people work involved, while many will likely prefer to deal with the clear, binary logic of computers. But for those who always liked to work on the edge between technology and people, this might just be the right career advance. One that’s surprisingly easy to make.

Seventy percent of the time Swiss

Boarding an airplane on Monday morning, coffee in hand, yawning, flying to Zürich for a week of alternating between the customer’s office and hotel, then back in the air on Friday evening to reach base—my home in Warsaw for the weekend. That was the offer I was given a while ago, good money, challenging work. I replied “no, thank you“.

Mind you, I am by no means bound to where I’m living currently, even though I love it here. There are many other extraordinary spots around the world where I could see myself moving. It’s just this particular arrangement that wouldn’t suit me—torn Schrödinger-style between two locations, neither really here nor there.

It would’ve uprooted me from all the current affiliations I had here, in Warsaw—the TEDx people, startup communities, Toastmasters and personal relationships. On the other hand, my temporary Zürich tenure (or anywhere else for that matter) wouldn’t have let me get engaged in anything meaningful there, since these relationships take time to develop and produce results.

There would be also practical consequences to consider. Since I would’ve been spending only weekends here in Warsaw, I’d want to maximize my enjoyment of them, so I’d have to pay somebody to clean my apartment, do laundry and arrange for all the other chores to be done, so that I can rest, catch up with family and friends. And I likely would’ve been spending vacation at home, sick of all the traveling.

There are times in life when that sort of work mode could be acceptable, perhaps even exciting. Usually that’s when one is younger, has no spouse, little experience. With time one learns that things of value require time and commitment to build, often related to one’s personal presence somewhere for an extended period of time. We might be living in a digital age, but we’re still very much physical creatures.

Antique inspirations for software architects

The Roman architect Vitruvius around the year 15 BC completed his impressive, ten-volume treatise on architecture—De Architectura. It covers every possible type of man-made structure ever needed by the people of his time, but starts out wisely by prescribing basic qualities that good architecture must embody:

All… must be built with due reference to durability, [utility], and beauty. Durability will be assured when foundations are carried down to the solid ground and materials wisely and liberally selected; [utility], when the arrangement of the apartments is faultless and presents no hindrance to use, and when each class of building is assigned to its suitable and appropriate exposure; and beauty, when the appearance of the work is pleasing and in good taste, and when its members are in due proportion according to correct principles of symmetry. [emphasis mine, and I prefer ‘utility’ over ‘convenience’ in the original quote]

Vitruvius, De Architectura, Wikiquote

Sounds familiar? It certainly did for me when I was brainstorming the set of values that our newly minted team of software architects was to adopt. Durability, Utility and Beauty described perfectly how I thought about good software architecture.

  • Durability means that software must stand the test of time. Work as long as necessary without crashing or requiring mid-way reboots. And it shouldn’t need to be rewritten from scratch every few years, but instead adapt well to changing needs. This principle guides the selection of languages, platforms, frameworks and tools.
  • Utility means the software must fulfill requirements that it was given and must do so well. If it’s a user-facing application, it must be easy to use and supportive, if it’s meant to handle high load, it needs to scale well. If it exposes an API for others to connect to, that has to be comprehensive and flexible. We need to build software always with its intended purpose in mind.
  • Beauty means the software must be pleasing to the eye. A clean, simple UI, laid-out and colored for readability. Inside, a logical layout of components, packages and modules. Good, clear but concise naming, plenty of whitespace, short functions, variables of unambiguous purpose. Computers will read anything. We need to code for people. This principle underlies front-end and coding style guides.

We unanimously decided to adopt these two-millennia-old qualities as our team’s values and to visualize them, I proposed an image that would become our logo: the Millau Viaduct—a spectacular bridge designed by sir Norman Foster, built near the city of Millau in southern France.

Millau Viaduct

Bridges ideally embody durability, some serving the public for centuries, like the Charles Bridge in Prague, opened in 1402. Getting people efficiently and safely across rivers, valleys and canyons is as clear an illustration of utility as we could hope for. And while beauty is in the eye of the beholder, to us Millau Viaduct truly is beautiful, with its slender structure suspended over the Tarn valley like a delicate web of strings.

We’re using these values to ask better questions. Is it durable? Will this fancy framework you have spotted at some conference be around in two years? Are you sure we need the user to click three times to submit the order? Can we make it easier? Can you read your own code? Can your new team colleague read and understand it? Old lessons that continue to hold true in an age technically so much more sophisticated than when they were put in writing.

Photo of Millau Viaduct by Phillip Capper.

The state of the craft at CraftConf 2015

CraftConf in sunny Budapest aims to be the conference in Central Europe where developers share what’s state of the art in building software. Joining the 2015 edition was an easy choice, after the first edition a year earlier received rave reviews from attendees. Three days, 16 talks and a workshop later I emerged with 6,062 words worth of notes, distilled into a few broad trends that seem to represent the edge of the industry right now.

CraftConf 2015 Stage

Microservices entering the mainstream

At SoCraTest 2014, less than a year ago, a lot of people were still asking basic questions about microservices—what they are, how to build them, how are they different from any other SOA approach. Not anymore. CractConf saw a lot of companies sharing battlefield experiences with these architectures—what works, what doesn’t, whether to consider the approach at all and how much it will cost.

  • Microservices are a means to scale the organization—allow many people to work on the same system, reduce dependencies, and thus enable rapid development without having to coordinate huge releases or continuously breaking one another’s code. They’re routinely described as “easier to reason about” and built to “minimize the amount of program one needs to think about” by the very virtue of being small and focused on doing one task well.
  • Microservice ecosystems at established companies routinely consist of 50+ and even 100+ services, usually built in a whole range of technologies. If a single service is small enough, say “2,000 lines of code“, or “takes 6 weeks to build from scratch by a newcomer” (both actual definitions), then building one in a wholly new technology is easily sold as an inexpensive POC.
  • All companies successfully implementing microservices started out with monolith applications and afterwards split out the services one at a time. This approach was broadly recommended, even for greenfield projects, because monoliths are easier to refactor while the organization works to research and understand its product better.
  • The supporting tooling is already there and mostly quite mature. Early adopters, like Netflix, had to build their own tools, which they later shared and improved with the open source community. Meanwhile, commercial tools popped up, offered by specialized vendors, with support contracts and other conveniences that pointy-haired bosses like so much.

But most importantly:

To benefit from microservices without getting killed, you need to:

  • automate everything—builds, testing, deployment, provisioning of virtual machines and container instances. It’s the only way to manage hundreds of running service instances.
  • monitor everything—each service must have its own health checks, showing whatever information is most relevant. Typically numbers of transactions, timings, latency, hardware utilization, but often also business KPIs. You’ll also need a means to track requests flowing through the system, ie. by IDs being passed in service calls. This information must be available to development teams in real time.
  • build for failure—crashes, disconnections, load spikes, bugs, all of which will occur more often than with monoliths. Make sure failures are reported, tracked, and the system is self-healing, via techniques like circuit-breakers, bulkheads or resource pools. Work with business representatives to determine for each use case whether consistency or availability are more important, because you cannot always offer both.

Not everyone was pleased with such a high degree of saturation with microservice themes at CraftConf:

But that only proves that this architecture is well past the stage of early adoption and entering into the mainstream.

Everybody has an API

The consequence of adopting microservices is that APIs become the norm, starting out internally, and often “sooner than you think” being made available to the outside world, either to support different devices or integrate with 3rd parties. Their costs also became more evident:

  • An API is for life. Once it becomes public, it’s very difficult to change, so early design mistakes become much more difficult to fix.
    • Use techniques that allow you to add new fields and methods to an API without disturbing clients.
    • Semantic versioninig, coupled with decent deprecation procedures, help move the process of making backwards incompatible changes.
    • You’ll still have customers who “missed the memo“, whom you may have to offer commercial legacy support for an additional fee.
  • Create good documentation, generated and published automatically.
  • Assign people who will be monitoring community sites, like StackOverflow, for questions regarding your API.

@ade_oshineye (of Apprenticeship Patterns fame) was spot-on summarizing the process of deciding whether to create an API by showing an analogy to puppies—everybody wants one, but not everyone is ready.

Moving towards Domain-Driven Design

Frameworks these days tend to dictate the design of applications by suggesting organizing code by layers into packages like models, controllers or views. The consequence is that:

  • modifications to a single business scenario require often changing code in many packages,
  • it’s all too easy for components to reach into layers outside their hierarchy, too deep down for their own good, while they should only be calling public APIs,
  • there’s very little information presented by the package structure on what the application does.

Several speakers postulated that this should stop and instead code should be packaged by business units, with relevant models and controllers sharing the same packages. Encapsulation could further be improved by changing method and component access to package instead of the common public. It’s an old theme that finally seems to be getting traction, with past support from developer celebrities like Uncle Bob:

What do you see? If I were to show you this and I did not tell you that it was a Rails app, would you be able to recognize that it is, in fact, a Rails app? Yeah, looks like a Rails app.

Why should the top-level directory structure communicate that information to you? What does this application do? There’s no clue here!

Robert Martin, Architecture, the Lost Years

Well worth watching.

TDD and Agile now taken for granted

Two themes notably absent from the vast majority of CraftConf talks were TDD and Agile. They implicitly became accepted as defaults—the baseline, cost of entry and survival in the game of software development.

  • Microservices will only reach their full potential when their owning teams can work and make decisions independently from central authority, including frequent deployments to production.
  • Frequent, decentralized deployments require comprehensive, automated test coverage.
  • TDD drives the design of code, meaning every line exists only to make a failing test pass. “Every new line of immediately becomes legacy code” so code as little as possible.
  • Google continues to build new tools to satisfy business problems they are facing—tools that often get adopted company-wide, but never enforced. They call it an evolutionary approach, where the best ideas will be adopted simply on merit, while the others will die in obscurity.
  • @cagan argued how the whole top-down oriented product design cycle is broken by being grossly inaccurate and too heavy, and companies need to adopt bottom-up idea spawning and rapid testing instead.
  • Transparency is key, so that everybody can make better decisions based on as much information as possible.

Oh, and “doocracy” is a word now:

A vibrant community

It’s been a blast to mingle with some of the 1,300 energetic attendees, meeting friends, old and new. @MrowcaKasia and @kubawalinski turned from Twitter handles into real, live, and engaging persons. The slightly grumpy but ever competent @maniserowicz is always a pleasure to meet, and then there’s the whole SoCraTes gang of @leiderleider, @c089, @Singsalad, @egga_de and @rubstrauber, whose passion for community and craftsmanship continues to inspire.

The 2015 CraftConf was only the second edition, but already organized with such painstaking detail, that I can easily call it the best conference I’ve ever been to. The team’s already fishing out and working to improve what didn’t quite work this year, so next year’s event is bound to be even more polished.

A corporate career may take you places

Fame and fortune, in smooth ascent from line employment to richly compensated CEO, is what so many find appealing in working for global corporations. While not in vogue among the hordes of eager entrepreneurs and freelancers we have these days, for many people it remains a perfectly valid career choice. Success depends on how soon you’ll realize that this path is not smooth at all, often times surprising, and always comes with a price tag.

Big companies differ from smaller ones, or start-ups, in that they offer plenty of space. With thousands of employees worldwide, there is a broad selection of positions situated vertically and horizontally from yours, matching your ambitions and talents. They also offer greater liquidity (to borrow the investing term), in that at any given moment there will always be positions open somewhere. Maybe a person got promoted, leaving her past desk vacant, or maybe it’s a whole new opportunity—a new division being built or branch getting expanded.

Those windows are yours to take, providing you accept the conditions.

Since these companies operate around the world, your perfect opportunity might pop up somewhere far away from whatever you consider home now. Perhaps you live in Warsaw while a new office opens up in Singapore and needs someone experienced with the business to go set it up. You’re being offered the position, since you’ve been doing a great job so far and demonstrated competence beyond your current role. Here’s your airplane ticket and we’ll take care of shipping your belongings. What say you?

Dilbert sent to Elbonia

Make your decision

An eye-opening lesson I received a while ago from Garry Marsh, participating in his training, was that at all such crossroads one needs to determine:

What do I really want, what is the price and am I prepared to pay it?

Garry Marsh

Moving always means leaving behind pretty much everything you’ve built up so far. You know your town so well, how to move around, the friends you have here, your lovingly arranged apartment, even your favorite hairdresser who always has these great ideas for hairdos—all gone, you’ll start again from scratch. You may not even like the place you’re being offered. Singapore is nice, but what if it’s some poor, underdeveloped country, or a remote place with nothing but stretches of dust around?

Of course you can always say “no”, because you have your family and friends here, and everything you know and love—we understand, no hard feelings. But the next time a great opportunity appears, you might not be considered anymore, having been labeled as the “stay at home” type of person. Which is fine if staying close to home is your priority, but again, “home” is a much smaller pond than the world and so many fewer chances to win this lottery.

Make sure you set your values straight before an opportunity pops up, and choose accordingly. In the end, you’re in pursuit of happiness, so if you’re finding it at home, stay right there and look out for local options. If you do, however, decide to move around a bit, some preparations will save you from a ton of headaches.

Stay light

Certain decisions—like marriage, kids and buying real-estate—will impact your mobility, and need to be made thoughtfully. This isn’t to say you should stay single and live in hotels, but it does mean you’ll need a spouse willing to follow you, and that renting will likely be preferred to owning.

Case in point: a friend of mine was buying his own condo, where he was planning to move in together with his girlfriend. He signed the letter of intent and paid a small advance. Soon after they went separate ways, and he started to work remotely and travel at the same time. Needless to say, the apartment purchase was broken off and he lost some money on that—a cost he was willing to carry, and much better than falling for the sunk cost fallacy, but still avoidable, had he inspected his values earlier.

Make your everyday decisions mindfully—small and large things you acquire: furniture, kitchen appliances, decor, clothing. Would you really want to drag ten pairs of shoes across the world? Or this beautiful, gigantic picture from your living room? There are companies that make a lot of money offering “temporary” storage for people on the move, and you’re about to entrust them with all the stuff you never use but still keep “just in case”. Whatever you decide to store with them is probably what you don’t need at all. Get rid of it. And don’t assume you’ll come back. Maybe so, maybe not.

A radical, efficient way of cleansing your belongings comes from Paul Klipp:

A week ago I put everything I own into boxes. My closet was empty. I resolved to remove what I needed from the boxes, when I needed it, and to put it in the closet when I’d finished using it. In that way, as time goes on, my closet will become filled with only those things I really use. What’s still in boxes can be recycled, sold, or given away.

Paul Klipp, Stuff

A conscious decision and a light lifestyle. Certainly not for everyone, but if you think it’s for you, start practicing today. Talk to your spouse—that might be the toughest step, but providing you chose a life companion who shares your values, you should be fine. Review and purge your household of things you don’t use. Then do what you’re already doing—deliver excellent work, stay connected to a network of resourceful people and look out for your opportunity.