-
This was a great read, I’ve been using feature toggles a bunch recently to make multi-stage deploys go a bunch easier. One problem the team has been running in to is that we don’t have a good process for removing the toggles.
So: How are you being disciplined about removing these flags?
-
We’re not using feature toggles at my current job, but my approach in the past was to have three states for a feature. A Feature can be off, on, or not-present. Not present is equivalent to ‘on’, but it also generates a test failure that CI catches. All the features are controlled through a single file which is managed by the PO or whoever owns those things, and the build system notes how long ago the feature was set to ‘on’, after it’s been consistently ‘on’ for a while, it automatically removes the flag; leaving the feature ‘on’, but generating an error which a programmer has to go solve before the build passes clean. That reduces the discipline from one of ‘remember to remove these’ to ‘remember that the build must be green before it can go out.’ The latter is much easier to automatically enforce.
-
I wrote the linked essay.
There are many cases where I wrote something and my views moderated. I used to evangelize open allocation. I still think that it’s an ideal for a creative workplace environment, but I’ve grown older and recognized that it’s not always practical. You couldn’t have an open allocation trading floor.
My views on Scrum have not moderated. If anything, I’m more convinced that I was right the whole time. Pro-Scrum engineers tend to have a mistaken view that it provides real protection against management. If it did, it might have value. A prioritized backlog does help to introduce sanity. In terms of providing protection from management, it doesn’t. You can’t actually say to a manager, “We’re not doing this because our process precludes it.” I’m sure that Scrum has caused more people to get fired than it has prevented firings. Of course, what we’ve seen in software in the past 5 years is that management has co-opted Agile and Scrum as excuses for micromanagement and brutality.
All of this said, I don’t that killing Scrum will solve the core problems: business-driven engineering, low status for programmers, and the flooding of the labor market with unskilled replacement programmers (due to the proliferation of boot camps, and abuse of the H1-B program) who will work cheaply and take abuse. Like all fads, it will die at some point. As for the cultural change that it represents, I’m not as sure. Programming is one bad turn away from reverting to the status of being just another shitty office job. Winter is coming, and it’s time to start planning for it, and I think that many people who are strong enough to get out of the technology industry will do so.
I will say, it does depend on the environment. I’ve seen guys in our German office say exactly “We’re not doing this because our process precludes it.”, and amazingly, it worked. “Sorry, we’re not taking this task because it is not well-defined or prioritized in our backlog.” The problem is it requires huge management and upper-management buy-in, which is very very hard to do, and especially hard to do in countries where workers rights are not a fundamental part of your environment. But in my experience, when you get it right, I enjoy SCRUM.
I’m curious about your perspective on ‘business-driven engineering’. I have always thought that engineering is naturally a function of business. I’ve felt that engineering is there to serve the interests of the business level. Often times at small companies engineers who have solid business skills can do both jobs, but the split is still there.
What does engineering independent of business concerns look like to you?
[Comment removed by author]
The hub-and-spoke office seems like a good idea. What you want is a mixture of spaces. You want open spaces for when people choose to use them, and you want private or semi-private offices where the doors are usually open but sometimes closed.