Jettison sandbags to focus on your goal

Whether your deadline is near or far, there will always be things on your team list that you don’t need to do. It’s tempting to take ownership of everything, all the servers, all the code, all the admin. As a team of top developers, you could also write a better timesheet management software than the one you’re stuck with.

But should you?

Does it help you with your mission? Does it provide business value? Can you do it better and cheaper than what you can buy in? Do you have a unique circumstance that means you can’t just style an off the shelve solution? Really, are you that unique? Do you want to support it once it’s released?

More important than any plan is a strong purpose, a goal. Something small that everyone understands so that any task can be quickly evaluated against it. If the task doesn’t fit the goal, it’s irrelevant, ditch it. It’s baggage. Even if it’s an existing system.

What’s your team’s purpose? Or at least your 12 month goal?

The Fog

Dream in years.
Plan in months.
Evaluate in weeks.
Ship daily.
— @dpatil

— Michelle Lee 🐍 (@mishmosh) January 12, 2017

Agile is about the here and the now. The moment, turning on a sixpence as the weather, and the market changes. Adapting to your environment and delivering, delivering, delivering at a consistent high quality.

But what if you’re delivering the wrong thing?

It’s not just about the pivot, it’s about the plan and the dream. How can you decide between prioritising the mobile app or the chat interface unless you know where you’re going?

Yes, we prioritise, reschedule, re-evaluate constantly, and we only ever have a clear path for the next timebox, no matter how much our Gantt charts and managers persuade us otherwise.

But what are you doing next? Do you need to build your storage layer for SSDs or the cloud? Are you optimising for read throughput and fewer writes, or network performance and fewer reads?

Don’t let the immediate goal cloud your thinking. You may not be able to see clearly where you’re going in terms of detail, but you should be clear what direction you’re heading, where the big obstacles are, and who’s nearby.

Out there in the mists are the challenges, the gaps, the shortcuts and the dead-ends. Don’t shoegaze yourself into a corner.

Don’t forget, the feedback loops don’t stop at your retrospective intervals. Look up once in a while to make sure you’re on track.

Naughtonomy

Wherever the wind takes you

If you want a strong team of developers, give them autonomy. But what if they don’t want to take it? The ones in, or from, the big corporations who just won’t take the initiative? The ones who just want to be told what to do?

I’ve said before that those are the waterfall people. The cogs in the machine.

Have you been a developer who didn’t want to take responsibility for yourself or your work? Who doesn’t have pride in your work, and just wants the money? Do you want the opposite of autonomy?

It might not be your fault. If you live in a blame culture, you want to leave as small a footprint as possible. Head down, do as you’re told. Don’t attempt that risky refactoring or upgrade. After all, if you do it, and it breaks, it’s your bonus that gets lost, and your neck on the line for big failures. If you don’t touch it, and it breaks, maybe the previous touchee will get passed the grenade, or maybe it will just get blamed on a faceless, incomplete “process”.

Maybe your manager doesn’t want you making decisions. You’re not important enough. You don’t have the power to make them. Developer ideas don’t matter, listen to the manager, or the architect.

Or maybe you want to be motivated, to get autonomy and change things.

Show your boss this. Or get a new job.

A task/story is not a feature

Agile is easy. Take the requirements, break them down into tasks, schedule them, do them, review them, test them, ship them.

And then you realise, as many on the agile journey do, that your “spreadsheet import” task is too big. It doesn’t get finished in the same timescale as other tasks, so it sits on its own branch, drifting from the mainline, or it holds up the release until it’s done-done-done.

• As a user
• I want to import spreadsheets
• So I can use data created by other programs

Break it down. Make each task count. The feature fractures into tasks, micro-features, one for reading each format you want to support; one to deal with classes of bad data, those mismatched quotes and uneven lines, one for paging to deal with larger spreadsheets.

Just as we have to break down each interaction into multiple facets, and multiple services, to create the smoothest possible user experience, so we break down each feature into componentized tasks to let us integrate more often, review more often, release more often, and provide the smoothest possible developer experience.

If your process doesn’t flow, fix it, smooth it, deconstruct it.

Good developers learn

When I interview people for a job, I look for their skills, but most of all, I need people on my team who love to learn. I was thinking about this when I listened to Rick Strahl talking on .Net Rocks

When I started developing, there was a lot of talk about certifications and becoming a language expert, or even an expert in one aspect of a language. C# for web applications, for example.

Now, it’s no longer a matter of learning a technology. Good developers learn to learn. Understanding enough to detect smells in languages and frameworks and knowing how to trial and evaluate them. In an agile world, there’s no architecture team to dictate to you. You need to be brave enough and supported enough to make a good decision. Not necessarily the best, but at least not a wrong decision.

More than ever, with the architect hat on, we need to make quick decisions based on incomplete information and be willing and able to change if and when new information invalidates those decisions.

I have no doubt that .Net core is the future for the platform, but having made the decision to try it on a project, we had to change back to .Net framework because core isn’t ready yet. We needed experience to tell us that.

If you’re going to do something new this year, learn to learn. Invest in knowledge, experiment with new ideas and technologies, and document your discoveries, in a journal, a blog, a video, a presentation or a dictaphone, to give you the chance to reflect on what you’ve learned.

! Not the lazy programmer

There’s been a popular stereotype about good programmers being productively lazy. Automating tasks to avoid work. It’s an easy thing to share but I don’t think it’s quite true. It’s about reducing inefficiency.

It’s not that developers don’t want to work, we want to do interesting work. Not repetitive work, not work that gets binned, not work to make life miserable for ourselves or others, and not work that can be done easier, cheaper and faster in a different way.

At it’s heart, software is a process that turns data, sometimes with human input, into other data, and sometimes into information and insight. Great developers understand processes, sub-processes and the connections between them, and inefficiencies smell. They distract, like a stone in the shoe, or a dam in the river. Sometimes we can quickly throw out the stone and run faster. Sometimes it takes years of rubbing away, fighting the blockages, until the path is clear.

Sometimes we shave yaks (and btw, check out that gif), Not because we’re too lazy to climb the mountain, but because we know we’ll have a better chance of getting there with a warm coat and a good plan.

Don’t be lazy. Be efficient. Be effective. And route around or remove any blockages in the way.

Non-functional requirements and terrific testers

There’s a ongoing debate about non-functional requirements: Non-Functional Requirements Are Not Nonsense and it’s a debate I’ve had within my teams as well.

In most consulting projects I’ve seen, non-functional requirements are listed as a nice to have, rather than a must have. It’s not a matter of business logic vs. performance either. In one rare exception, I’ve had a requirement for an import function to load and validate millions of records within a 48 hour period. If the import wasn’t correct and wasn’t fast enough, the requirement was not met. We made it with room to spare.

I think one of the key problems developers have with non-functional requirements is that they aren’t tasks to be achieved then ticked off, they’re cross cutting concerns, and are often best effort, so don’t need to be 100% complete to be ready to ship. They can be continually refined.

This can be hard for binary developers to grasp. Tests pass or fail, requirements are complete or not. And in a pre-devops world, many of the factors affecting them are outside the control of the developers. You can’t have 99% uptime on a VM that’s off for 30 minutes a day to be backed up.

Good testers help to bridge the gap by turning an aspiration into a target. They hear the customer wants the website to be fast, and they write 95% of requests return in under 250ms. Browser compatibility goes in the test log, because “the current version of…” is a moving target.

Not that we pass responsibility for meeting the requirements from developers to testers, but we get the testers to turn something vague and system wide into something tangible and testable that the business owners and developers can agree on. After all, if it can’t be tested, there’s no way to measure of it’s done.

Most of all, it’s about explaining to business owners that an aspiration is not a requirement.

How do you know when it’s time to move job?

Around 18 months ago, I decided I needed a new job. It took almost 8 months to find my current job, and I swayed between wanting to leave and wanting to stay. In the end I discovered that I was finding excuses to stay because I’d been there long enough, and made enough friends, to be scared of leaving. But the company I left was a very different company to the one I joined.

If you’re starting the new year after some time off, starting to fear going back, or having doubts about your job, have a think about these things, and see where you stand. Then decide if you want to stick or shift.

Some of these are things I’ve felt, others are ones that came up from multiple people in recruitment interviews I’ve done over the last few years.

• You don’t see yourself here in 5 years
• You have more direction than your company
• You’ve lost sight of, or respect for, the company values
• You do all your learning, and all your best work, out of the office
• The idea of doing the same thing next year fill you with dread. But it’s exactly what you expect
• You’re ready for the next step, but you can’t see where that step is.
• Your team, or your company, is shrinking, and no plans for growth are forthcoming.

What’s made you switch jobs?

My 2016 in review

2016 was a big year for me. A new job, a new house and the first full year following the John Sonmez blogging course. I got back into public speaking, with my talk about APIs, and the follow-up usable APIs guided conversation at CodeCraftConf, although I missed out on the return of DDD Scotland.

I learned a lot. About leading and mentoring teams, about recruitment, about software design, about code quality, and a lot more things that I never had to consider in previous jobs. Things I was aware of, but now I have to make decisions about.

2016 has been my best year ever on my blog in terms of views, comments and visitors, so many thanks to all of you for your time and contributions here and on social media. My most popular post this year was “Don’t take your laptop home” – I don’t know if that struck a particular chord with people about work-life balance, but I know it’s something I’ve reflected on. I also see that my 5 year old post on the “Professional Development” and “Agile Is Dead” open discussions at DDD Scotland 2011 remains popular. I don’t know which, but either of them are great topics for reflective developers to consider : What does Professional Development mean? and What is Agile?

Looking to 2017

I’m not planning anything quite as dramatic for 2017 as a new job, but I still have some thoughts to share thanks to moving from consultancy development to product development and how things which once seems essential now no longer apply.

I’m also having more of a think about Conway’s Law as friends move into new companies and I reflect on the companies I have worked with. As a technical leader who wants a flexible, resilient software architecture and a passionate, always-learning team, how much can I influence one to affect the other. I’ve got a few thoughts on this, but I’d love to hear from anyone else who’s exploring this, as I’ve got a few bigger ideas here.

And I’d love to keep up 2 blogs a week, playing with styles and topics. Exploring old and new ideas. I’ve got enough topics on my Trello board for 18 months at that pace (including one describing the Trello board). If I manage to carve out the time to do that alongside my other commitments, you’ll see it here.

I don’t do New Year resolutions. It’s always a bad day to start something. Always reflect, always refine. And if you leave it to New Year, you’re only giving yourself 70-odd chances to change. Why limit yourself?

Sláinte