The modern workplace demands flexibility. Sometimes to accommodate work, because international companies need to work to international timezones. Sometimes to accommodate life. Don’t discount good staff because they have childcare duties, or other demands on their non-work time. 9 to 5 isn’t the only way, so long as people do the work and are involved in the right conversations.
As a worker though, that flexibility in hours means that sometimes you need to work after bedtime, or you need to learn about a new technology in an evening or weekend event. You don’t stop thinking when you leave the office, but you can stop taking every call.
The modern workplace is noisy. It’s full of distractions. Go home and disconnect so you can have the peace you need to get in the zone. But put it in your calendar, in advance, so no one is surprised.
But only take what you need. Prepare your equipment and your space. Make it productive.
You have a massive data set. You have geolocation data for the entire country. You are the king of GIS. And to prove it, you’ve developed a postcode lookup so people can check your database.
Your clients write their code and format their postcodes, and, like every other system they use, they expect that submitting a postcode will return an address. You’re the GIS expert, and you say the result should return Easting and Northing, because that’s what your database uses, and your database is right.
The clients look at the result, realise that your API returns garbage because it’s not using the language they expect, and move on to another provider.
To fit a good work life balance, your work should stay at work. My previous job supplied me with a laptop and rules, when working at certain desks, that I had to take my laptop home “for security”, and it became second nature to carry a heavy bag with heavy laptop, heavy notebook, and several printouts, because I’d need them.
It made sense for the job. I was on client sites a lot, and didn’t know when I’d have a network connection, so I had to take what I thought I’d need with me. And I’d check email on my personal phone because 3g/4g is far more available than WiFi.
I told myself it was OK because I was using webmail so I didn’t get notifications on my phone. But then I got phone calls on my mobile. At night. On holiday. Boundaries crumbled, and yet my bosses had it worse. They’d give me battle stories of weekend working and lack of sleep, as if poor planning at a company level was something to be proud of.
Let’s be clear. A culture of antisocial hours is a failing culture. A culture that bleeds onto personal devices when I pick up the cost is a failing culture. A culture where people brag about it is a failing culture. A culture that asks for a hackathon to work on things no-one can get a budget to fix is a failing culture.
I’ve heard horror stories of companies set up for one or more of the above. It happened to me occasionally on the odd project, and when I was leading, I made it my responsibility to identify and fix the root causes. Failing once is a good opportunity to learn. Twice is a warning. If you fail the same way 3 times in a row, it’s a dysfunction you should stop everything to correct.
I don’t have a laptop bag in my new job. I have a place to leave it overnight. I don’t need papers to visit clients. It’s lightweight, and technology has moved on so WiFi is available. Taking a laptop home is an exception, not an expectation.
To those who need their laptop out of the office:
Travel light. Small notebooks are better, tearaway pages are better still.
Don’t bring your own device. If a company needs you to access work outside the office, they will pay you to do so. Or at least give you reasonable compensation. They’ll have a sane home-working policy, or a laptop-installed communication channel. If you can’t use Unified communications, or at least VOIP, things should change.
Treat long hours as a bug. Fix it. If the company can’t fix it, the culture is wrong.
Antisocial hours may be required, but they must be compensated for in whatever reward suits the worker best. And planned ahead whenever possible.
I was disappointed to miss DDD Scotland this this year, as I was looking forward to catching up with everyone and giving my talk. I’ll have to do the catching up another time, but if anyone wants me to give the talk, I’m available for conferences, user groups, weddings christenings…
There’s still a few discussion points I want to have around the talk, so I’m going to be posting some themes from the talk over the next few weeks to see what you think.
I wrote the talk as a catharsis for a project with 3 very bad APIs. I don’t want to name them in the talk because none of them were the first time I’d seen the problem, and I’m trying to list general anti-patterns so that other developers can avoid the pitfalls. The key one being that for all the user experience research, most people still think of users and interfaces as graphical, not programmatic.
Before I start the rants though, I want to start with 2 thoughts about making an api that sucks less.
Test-first
The best way to think of the user first, is to be the user first. That’s why I like Test-Driven Design. Write the API you want to use, then figure out all the horrible contortions behind the scenes to make it happen. That way you’re far less likely to introduce unexpected preconditions, because they’re harder to test. You’re far less likely to expose internal domain terms and models  so long as you’re not thinking about them yet. And you get to experience any frustrations first hand when you’re best placed to fix them.
Use BDD, use xUnit, use Postman, use the wonderful new .Net core
TestServer.GetClient()
. Keep using them. Don’t accept any pain in your interface tests.
Rest, and be thankful
The talk unashamedly focuses on Web technology, and REST, for all the trial warfare, is a great way to think about the interface, and some of the basic lessons apply to other interfaces too:
Be open for extension – where you can, build extension points into the interface. Use dynamic models if you can, allow discoverable interaction (I’ve got my order, what can I _do_ with it?)
Use the standard – if you’re building on top of http, use headers, content-type, appropriate verbs, because existing clients and test frameworks support them, developers have learned how they work from other interfaces. Don’t be the stone in their shoe.
Minimise state transfer – don’t ask clients to remember, don’t ask clients to send or receive large amounts of data. Scope requests to the smallest sensible unit, and only ask for what you need.
Anti-patterns
Sometimes it will go wrong, and you will make developers cry. I’ll start talking about those next time but feel free to add your own below.
One reason I don’t trust change is when that change has no defined end goal. When a change is requested, and the ticket completed, but it then enters a cycle of scope-creep that means the ticket can never be closed.
They often start with something simple e.g. “can you improve the performance of this search”, with a simple tweak – add a JOIN clause to avoid SELECT 1+n queries. In some cases the user acknowledges the improvement, but some users will start pushing new features against the request “because it’s in the same area”. After all, changing the colour of the links on the search page is still part of the same use case, right? And the fact the search is still slow when I use this rare combination of fields means the original ticket wasn’t fixed.
Close it and move on
In some scenarios, it’s easy to be brutal. These are time-bounded sprints, so anything raised must be factored in. This works where features and bugs are interchangeable and represent simply “work to be done”, however they are charged, and let the retrospectives and other analysis worry about whether any particular piece of work is a bug or a feature, so that the team can ensure it’s delivering the best business value.
The definition of done needs to be clear from the ticket (although maybe not to the detail of a SMART objective, it’s worth thinking about that framework). If the provided steps no longer produce an incorrect result, or a speed improvement is recorded, or some other pre-defined success criteria is met, then the ticket is done. Any further discussion is a new ticket. If the objectives aren’t met, it should not be marked as done and the developer should continue work on it.
It’s under warranty
Many software products and projects have a grace period of warranty, where bugs are fixed for free. This is typically useful to resolve conflicts in untested combinations, or volumes, but it can also be used as a stick if the developers aren’t careful. Provided the warranty period is reasonable for the size, complexity and support arrangements within the project, bugs should be fixed to ensure the original scope is delivered. Some customers will however try to extend scope by issuing bug amendments to change scope, under the guise that the bug was raised during the warranty period is therefore should be resolved. After all, bugs should be fixed, but features must be paid for.
Make sure you have a good rapport with your client, and make sure the terms are clear.
Decide now what done means, and how to manage tickets
The last thing you need is to decide this when the tickets that’s blocking the release gets re-opened for the 100th time because the CSS is broken in IE6.
I’m thinking about the planning and estimation process deeply, because it’s taken up a lot of my time on fixed-price projects.
I think my biggest problem at the moment is trying to square the circle of the 4 purposes for the planning and estimation we are currently doing, in order of detail : scoping, horizon planning, just-in-time planning and change control.
Scoping and change control are the most important to the project board, horizon planning is most important for setting deadlines for deliverables to and within the project team, and JIT planning allows us to define work at an individual level over a sprint.
Scoping
Scoping has and, I believe, will continue to be a horse trading exercise, allowing us to talk in broad terms about including and dropping functionality, based on workload, risk and timescales.
These scopes are defined mainly from the initial bid and budget and have undergone minor changes.
Horizon Planning
The horizon planning is the key deliverable from last week’s planning meeting and today’s requirements discussions : making sure we set deadlines for delivery of documentation and components to an agreed timescale.
Just-in-time planning
JIT planning is the bit the whole team should be involved in. It’s how we break down the tasks and decide what and how much we do in the next sprint, at a level of granularity that minimises crossover of tasks between developers, and therefore maximises parallel execution.
Change control
Change control requires estimation at a lower level of detail so that we can identify any difference in expected effort between our current plan and the results of any workshop. This must be done before the use cases, but to a similar level of detail, and we will need to add a step during the production or review of those use cases to highlight variations, so that we can suspend delivery of those use cases until the change has been managed.
I understand why, for political reasons with certain customers, the change control detail is necessary, but I prefer to ensure the wider team remain focused on the horizon and JIT planning, to shield them from the politics that may cause disruption within the team.
How to keep engineers interested, and understand the people the company is so keen to tell us are the core of the business :
engineers love problems, keep the work interesting;
engineers are creative. Give them space to do so;
engineers need autonomy to do the above;
we do the work we do because no-one else has solved the problem before. That means we fail sometimes. We need the freedom to fail and recover, because sometimes new things don’t work;
engineers love creating value. If you want to demotivate them, give them meaningless work that no-one will see. We want projects that people will use.
Craig Nicol 