Heed me, oh working class. Corporate America will replace any job they can with a robot. It is so.
How do my Republican associates square “a plan to close the gap” with simultaneous record corporate profits, record unemployment and an adversarial stance against raising the minimum wage?
My friend James Spargo recently sent me this article on feature branches by Martin Fowler in which he criticizes the “feature branching” approach to software development. In essence, feature branching endorses an approach where changes to a computer program are made in an isolated container (the “branch”) until they reach a certain level of readiness. Mr. Fowler believes, instead, that these changes should be folded in quickly so that the there is communication among the other participants in the project.
Mr Fowler is a smart man but at Brainfood we feel like our lives became less complicated and more productive with the adoption of feature branching. Our process up until then had classically been all of us pushing into a single branch and rarely keeping many branches around. The excellent and experienced staff at Eucalyptus Systems dragged us into using feature branches and we’ve stuck with it. Having experienced both approaches I’ll briefly outline what I see as the benefits to using feature branches.
Life puts you through big changes
Though Mr. Fowler prefers to steer clear of branches he does advocate the sensible policy that each commit should be “ready for production”. It isn’t clear to me how this is achievable for non-trivial refactorings. There are plenty of occasions where the changes a piece of code needs are small and can be written quickly and committed but certainly not all situations are like this. The treachery of multi-core programming can easily put you in a position where you need to rethink the way a whole group of components interact and those components may have mature and widely deployed interfaces. At the same time, the show must go on and you may have work that needs to happen immediately while a large complicated refactoring is in process. In a situation like this its hard to see how a “one branch to rule them all” approach is going to get the job done.
Protecting yourself from yourself
Another corollary of the single “always ready” branch model is that change streams probably end up staying on your desktop until they are ready. Mr. Fowler even advocates that “every commit should be ready for production”. To me this adds up to people keeping substantial chunks of work in the working directory of their desktop until they have everything working. This is a recipe for either losing a bunch of work or screwing up a bunch of useful work because you took a wrong turn halfway through. Computers break and people sometimes write bad code after working a long time. With feature branching you can push and push your changes into your own isolated branch without bothering anyone else in the project. If you take a wrong turn you will also have a series of snapshots so that you can roll the tape back to the point where you took a wrong turn.
If you work on multiple computers (home, work, laptop, etc.) pushing to branches in the team repo is also a convenient way to hand your own work between environments. You can definitely get there with a peer to peer approach but sometimes dealing with a single well connected host is easier than the VPNs and SSH proxies that may be required to get all your machines talking to each other. Sometimes, because of policy, it may not be possible at all.
Another beneficial side effect of feature branching is that your work in progress is encoded as a convenient artifact that can be passed around to other members of the team for review. In Mr. Fowler’s approach, the team finds out about your changes because they are literally stumbling across them. A formal review process doesn’t seem possible because the commits are frequent, fragmentary and continuous.
With feature branches it is a common practice for one or multiple members of the team to review your branch before it is committed. Since the changes occur in a branch there is the convenience that the work will be cleaned up and thought through before someone else has to grok it. There is more of a chance that the changes could be ill-conceived and have a lot of work in them since they occur in isolation. It seems like the cure to that problem, however, is to have other team members take a peek at your branch before you get too far along.
At some level, each time we begin typing we are potentially taking the whole team on some flight of fancy springing deep from within our mind. With feature branching the rest of the team joins that jaunt with a greater degree of complicity. When the changes are rolling into the master branch all the time you can complain but you will need to be very vigilant or you could find yourself along for the ride.
My final criticism of the CI all-in one-branch approach is that people inevitably make mistakes. I’m not talking about typos but about big conceptual miscues. In the “along for the ride” model you may find that your stream of useful changes is interleaved with some tragically misguided work and you failed to notice it because you were so focused on the task at hand. Your other team member may even realize it and be trying to unroll the changes. Unfortunately, the work is now tangled into your work and you may even depend on parts of their stuff that worked well enough for you to remain oblivious to the problems they discovered.
Certainly there is a danger to people sitting on their work with the feature branch approach. You do not want someone to carve of their own little playground and go on wild sprees of modification while the rest the project leaves them steadily behind. If you are pushing branches back to a central point, however, and tracking progress with a ticket system (we use Redmine Backlogs) then you have great management tools to fight these problems. It seems to me that with the single branch model you have intrinsic problems that can’t be fought through management tools. For us, at least, that has made feature branching seem the better model.
I’m surprised to see that SteamOS hasn’t impacted the popularity of “Debian” as a search keyword. So far, the search frequency remains fairly fixed:
The popularity of “Debian steam” and “SteamOS” is exploding:
So its odd that there is no impact on the popularity of Debian itself. I can only suppose that the search activity for “Debian” is already very large and stable so that the impact of Steam is minimal. That’s still surprising though. I would expect it to trend up.
Yesterday I bought one of these little guys off of Amazon for $17. Its a tiny ARM based computer that was built for instant messaging. Amazingly, it has WiFi. For under $20 you can have a tiny, tiny computer. It also apparently exposes 10 GPIO lines on its “docking port” so you can really think of it as a cheaper Raspberry Pi with WiFi, a keyboard and a display for half the price. Cool thing!
Kathleen Sebelius recently announced her plans for moving Healthcare.gov forward. Inspector General Dan Levinson has been enlisted to review the entire effort. The Center for Medicare & Medicade will create a full-time risk management position and Jeff Zients‘ company QSSI (now owned by United Healthcare) will continue to manage the day-to-day operations of the web site. Answers about who is in charge are coming quickly enough but the details about what precisely went wrong don’t seem to be as forthcoming. (edit: Jeff Zients is not the owner of QSSI. Mr. Zients will serve as the program manager for Healthcare.gov and manages the relationship with QSSI, the prime contractor)
The Healthcare.gov website has all the makings for a new era of government. From its start as an Open Source project in a garage to its rapid ascent to the forefront of national discussion, we have never seen a situation where politics and software were so entangled. The Obama administration has always had the attention of the Free Software movement. From its focus on transparency to its Drupal powered White House website, it seems to embody the values of the Internet culture. This affinity rose to a crescendo when Healthcare.gov managed to tie the success or failure of an entire Presidency to a single piece of software.
This phenomena of legislation merging with software may very well be a harbinger of things to come. Government has historically been a creature of papers. Armies of bureaucrats keep the cogs of the state moving by following the policies printed up in manuals. The government was certainly the first to adopt computers but its paper machinery is vast. Healthcare.gov hints at a future where legislation emerges not as a new flavor of paper pushing but as software directly facing the citizen.
For a long time people have understood that governments with secret laws, secret policies and secret courts are hazardous to the public’s health. The world has seen enough sneaky dictatorships to want these things nipped in the bud. Unfortunately, not so many people have grasped the possibility of a world where laws, policies and courts are replaced by software. People still think of software in the terms defined by ints private enterprise origins. It is viewed as property, belonging to a person or enterprise. People don’t give a second thought to the fact that there are powerful systems managing their day-to-day welfare that are pretty much entirely secret. Where the line between software and the law lies is suddenly becoming a lot more blurry. Between Healthcare.gov and recent revelations of the NSA’s capabilities we have been thrust into a bold new world.
Its easy to dismiss these thoughts as paranoid. The IRS has used software to manage people’s taxes for decades. Every part of government from Federal agencies to the smallest city department uses some kind of computer to keep track of data, so what is so different? Maybe the important thing is that the newer generations of software are moving from helping government employees find information to actually making decisions. Police departments use software to examine outstanding warrants, correlate them with social media activity and select potential candidates for enforcement. With the NSA under scrutiny for letting thousands of agents listen in on the conversations of so many citizens they have the motivation and the capabilities to replace those agents with software. How long will it be before the software is requesting court orders directly?
Backing Away From Open
It is ironic that one of the first reactions to Healthcare.gov’s problems was to close down access to the source code of the front end. The front end was the only part of the system that actually worked reliably and it had been developed in the open from the beginning. This must have stood in uncomfortable contrast to the rest of the system once things started breaking down. Eric Gundersen, the president of the organization that developed that software, said “If people had more insight into the code, and it was open, a lot more people would have a sense of what’s happening.”
The most important thing that the government can learn about Free Software is that it isn’t a product, it is a process. The reason it succeeds is because if someone really cares about a problem they can look into the facts of the situation for themselves. It is comforting that Mrs. Sebelius put strong and capable managers on the Healthcare.gov problem. Unfortunately, the removal of the Healthcare.gov code and the lack of answers about when that level of transparency will return begs for more than a list of names. If we are to believe the critics of Obamacare, our entire future and the welfare of our nation hang in the balance. If that is truly what is at stake then we should have our nation’s experts, all of them, looking at the code for that system.
How do you create reputation without compromising privacy? Ideally, you would like to trade goods with people using BitCoin directly but how can you know if the other party is trustworthy? You can take a “web of trust” approach where the people you trade successfully with sign some sort of document that described the transaction but then everyone else can see your trading partners. That’s obviously undesirable. Any thoughts?
I switched from MOG to Spotify now that they have a Linux client in beta. I have to say, the music discovery and friend integration is much better and I have *WAY* more friends on Spotify. MOG’s web client worked terribly on Linux and most other platforms from what I read. Streaming would constantly choke and stutter. I ended up mostly listening on my Android phone, which is OK but isn’t really the service I was paying for. Now that I have a working desktop client I find myself listening to a lot more tunes.
Of course, I wish the desktop client was Open Source but at least there is Linux support and at least it works and works well!
I started running Debian around 1995 after starting on Yggdrasil in 93 and playing around with Slackware for a while. Once I found Debian, I didn’t switch again. I’m typing this on my Debian desktop at home and will go get on my Debian workstation at the office in a bit. All our servers, both in the office and at the Via West colo, run Debian. I wish my phone did too.