Writing Software vs. Building Political Parties
I had a spectacular day with Jeff Blodgett talking with Alberta Party constituency Associations. It’s been driving me to finish the thoughts I’ve been germinating for a couple of weeks. Jeff had a useful conversation with us, I think we all benefited from the exchange. I feel a little more prepared and a lot more energized to change something for the better.
I’ve worked longer than I should have to try to express my thoughts clearly and in a useful form. I hope this works somewhat as a mirror of what I personally took from what Jeff told us.
The Alberta Party: We listen.
Our party was founded on the principle of The Big Listen. The Big Listen wasn’t one single event. It was - and is - a process of discovering the problems and pressures, but also the dreams and aspirations of Albertans. Not just a few Albertans who want to drive policy, but to find the common grounds and common interests we all can act upon. We have established a really great start. We have defined five points where Albertans have reached a consensus that we need action and we are at the stage where we need to refine our policy.
I want to address a slightly different angle on why listening is so valuable. Getting grassroots opinion and ideas are, of course, critical to a party such as the Alberta Party. In fact, we literally could not exist without it. But there is a different reason why our diversity gives us so much strength and insight.
I don’t want to address the sharing our problems or our values today. That’s where most of the people have been stopping in their analysis.
The Big Listen also involves sharing our experiences, our history, our personal discoveries of what brought us both successes and failures. It’s the blending of our expertise that leads to new insight.
I am not much of a programmer, I’m primarily the guy that keeps the computers patched and secure and fixes any and all problems that arise. Hopefully I avoid problems in the first place through preventative maintenance, a good backup regime, and hopefully being judicious, preemptive and through introduction of new, useful and appropriate technologies. I still understand quite a lot about how software gets made. There are entire shelves of books written on the subject, but don’t fear that I’ll get technical and continually throw jargon at you. The ideas to follow should be simple enough for everyone to understand. I’m going to significantly simplify things, so don’t expect to finish this as an expert in software engineering or project management, okay?
Software gets written for a vast number of reasons and for a great number of motivations. Not everyone is trying to make the next great game. Not everyone is trying to create the next facebook or the next twitter client. Not everyone is trying to find a better way to deliver your email. Hey, not everyone is even trying to make a profit! It’s that diversity that makes your computer experience worthwhile. It’s that diversity that gives you the ability to read this very blog. The quantity of software needed for you to read this very sentence is staggering.
Software usually begins as a good idea to solve a particular problem. Typically it will start with one programmer working on his (or her) own. As the project grows, the program may be incredibly useful and popular, and there is a need to increase what it can do. Bugs will be discovered and need to be fixed. It becomes impossible for a single person to manage the entire project alone any longer. There needs to be a method to increase the numbers of people working on the project. It might not be too bad when it’s a programmer and his buddies working on program, but it gets more complicated when you need a large team of people working together. That creates even more new problems with many people working on the same thing at the same time.
The variations in the process of software engineering are unfathomable. There are many different ways to add people to your team. There are vast differences of how you can deal with people making changes to the same program at the same time. I know very well that I am speaking in the broadest of generalizations. The point I want to make is that although there are incredible challenges with writing something as complicated as an operating system, we have done it many times over and we’ve learned how to successfully create software.
Granted it’s a tricky process. Making all this software work together is no easy feat. There’s a great reason why your computer crashes occasionally. There’s a reason why you need to “patch” your computer and keep it up to date with the most modern software available. We’re fixing and updating this stuff all the time.
So I’ve laid out some of the problems of how we create software. What about the solutions we’ve learned?
The very first book of significance on writing software that I know of is Fred Brook’s “The Mythical Man-Month.“ Without question, it is the Bible of Software Engineering and I’m going to prove Brook’s quote that, “everybody quotes it, some people read it, and a few people go by it.”
The very, very simplified gist of it is that adding programmers to a project that’s already running behind schedule will not speed up the process, it will actually slow your project down as people trip over each other. You can’t just throw money and resources at a problem and expect it to work itself out. Solutions have to be planned and managed.
The way I prefer to work around this problem is to keep the parts as simple as possible, then give standard ways to let the parts talk to each other. Little programs that do one thing only, but do one thing really well. Every piece has a role to play in the overall system. Should there be a big problem in one piece, we can take it out and replace it with a similar program.
The second analogy I want to discuss is a much hotter argument in software development circles. By merely mentioning “Agile vs. Waterfall development” I’m going to have hordes of extremely passionate programmers telling me why I have it totally wrong.
In it’s most simplistic form, the Waterfall model means the problem is analyzed for what’s needed, then you plan how you’ll create your program, after that you actually write the program, finally testing what you’ve done. If you need to fix bugs you do it in after the program is done by sending patches.
Agile is substantially different from the above. Instead of having a specific development route, Agile tends to be more cyclical. You figure out what you need the program to do and at the same time you figure out a way you can evaluate that your program does what it’s supposed to do. You test as you go. If you need to fix bugs, you’ll have to evaluate whether it absolutely has to be fixed right away or if it can wait until the next cycle. Sometimes the problems aren’t that serious and you can focus your effort on more important issues. Other times a bug you thought wasn’t serious turns out to be a major problem and it has to be made an immediate priority.
Cycles come on a frequent enough basis. You’ll agree on how long a cycle is - usually the programmers will choose a cycle lasting one week or one month. That’s often enough that you don’t need an elaborate planning session but gives you enough time to do something significant. Sometimes you’ll set major milestones on a quarterly or yearly basis for an in depth evaluation.
A couple of really basic points that often gets buried in the arguments: Agile isn’t really new, it’s been kicked around in various form for about 50 years. The incarnation we now call Agile really began ten years ago, but concepts have been around for a long while and are tried and tested now.
Also, I don’t know of any software that is produced through strictly one model or the other. It tends to be more of a continuum where developers choose tools appropriate to their development. Even the most adamant supporters of each model tend to take just a little bit from the other camp.
There are clear advantages from each model. The Waterfall Model flows in one direction and has a logical progression from one step to the next. It tends to provide a fairly consistent result at the end and it feels wonderfully familiar because it’s been used successfully for so often. Large and complex projects tend towards the Waterfall Model.
The Agile Model tends to have responsive outcome. Because the cycles occur frequently you know that improvements or fixes are always just around the corner. It includes continual evaluation of what you’ve done and continual feedback is sought. Agile remains adaptable to circumstances and you can reorder your priorities if necessary.
There are disadvantages to each as well. Waterfall projects are resistant to change and it can be hard to adapt in mid-stream. It’s like building the perfect car, with the perfect engine, the perfect interior, perfect brakes, perfect comfort and the customer comes back and says, “I love it! It’s perfect! Do you have it in green?” and the best you can offer is, “We’ll have one shipped out in 4-6 weeks.”
The disadvantages of Agile is that you are reliant on a good project manager making sure that everyone is on time for each cycle and that all the planning will still integrate together. Each person needs to deliver their piece on time and according to plan. The other disadvantage with Agile is that it’s so full of jargon my eyes glaze over after a couple of minutes and I tend to say, “Yeah, yeah, shut up and just get it done.”
So the Alberta Party has struck a new course that hasn’t really been traveled before. There’s an analogy here that will prove to be incredibly useful for some.
The Big Listen was hugely beneficial to the Alberta Party in so many ways. It was the seed for our policy. It was the beginning of establishing an open and honest conversation with Albertans that has been lacking.
The simple act of listening to what Albertans have been saying opens the door to hearing new solutions, new ideas and new ways to find success in our world. At no point have we lost any of the old solutions we value. We are truly free to choose the best answers and apply them to our future.
We cannot continually throw money and resources at our problems, slashing blindly when we run short of money and resources. We need a plan, we need true leadership, we need to develop real answers for the issues we face together.
We need to listen to Albertans and allow them to find their own roles where they can participate in our democracy. Some of us will only vote every four years, some of us will run and lose, some of us will run and lead. We want as much diversity and welcome as many viewpoints as we can reach so that we can discover the innovative solutions. Fully 60 percent of Albertans need a way to find their voice.
The Big Listen also takes on a very special role in that new course the Alberta Party is charting.
I see the Alberta Party as following an Agile model in our development. It’s something that is new, attractive and engaging. No one has tried it exactly like this - it was previously impossible without tools such as social media. Only the Alberta Party can deliver this model right now because we built our party on this principle. Most parties have followed the Waterfall model and will need to make institutional change to do what we can, and that’s hard. Remember, there is no right or wrong model and we have seen incredibly successful political parties using different models.
All that we have heard through the Big Listen has formed the basis for that very first evaluation of what we want this “program” - this political party - to achieve. We have been given the gift of an incredibly detailed document listing needs and desires of Albertans. We have been given the task to accomplish, it is our duty to build our party and succeed.
Developing an agile party will have challenges. Our developers are ourselves. We have to continually think about how we will test our program to ensure it performs as we intended. We have to set our priorities and decide what is most important to us to achieve for Alberta. We have to agree on how long our cycle will last and work within each cycle to be responsible and accountable for our results.
Ultimately, we will have a milestone every four years or so when we hold an election.
But the single, most critical aspect is that we need to continue doing what we excel at doing. We listen. We use that feedback to evaluate our work in that cycle. At the end of that cycle we need to listen and ensure that we got it right and that we have kept in touch with Albertans.
Our leadership must lead. They must manage realistic goals each cycle and ensure they are met. Our members must stay engaged. We all need to be accountable towards each other. We need to find ways to communicate with each other effectively. Sometimes we’ll borrow great ideas from the Waterfall model. Sometimes we’ll create new ways to get incredible results no one has dreamed of before.
Earlier I spoke of how many people have stopped their analysis at the point that the Alberta Party listens to Albertans’ needs and aspirations. I want to try to extend that and suggest that the model we are pursuing is proven successful and is completely unique to the Alberta Party. It is up to ourselves, the developers, to turn the Big Listen into positive action for Alberta, one cycle at a time.
There is a place for every single Albertan to have a voice. There has never been a better time to participate with the Alberta Party and to get your voice really heard.