Category Archives: Software Development

Tech Cities 2016 turned out to be a quick half-day conference, high on fun and low on pretense. I mistakenly thought we had an hour to play the Agile Architecture game, which was already a short time for explaining the rules and playing once through, but it turned out we only had 45 minutes. Generally we like to have 90 minutes and 2 hours works best. Kevin Matheny and I cranked through our short presentation on Agile Architecture and the rules of the game and jumped right into playing it with ~40 of our new friends.

We always played the game with software people in the past, so there were a few more questions about how to play than we’ve seen in previous games. But with a lot of individualized attention from ourselves and our three additional proctors, everyone was able to get through the game without being fired! Some even earned some gold pirate coins for completing their objectives!

If you have an interest in learning what life is like for an Agile Architect, let me know. Kevin is putting together these workshops going forward and I’ll be helping him out when I have the time.

I was playing around with the new xcode 7.2 which allows you to beta test applications on your own phone without an Apple developer account. Add to that the barometer available on the iPhone 6s and I just wanted to see how hard it was to write an app that can show you your altitude.

This seems like it would be pretty straightforward but it turns out there’s practically zero documentation on how to use the altimeter, and for a Swift newbie, this turned out to be quite a problem.

All I wanted to do was create an app with one button to start the altimeter, and a label which constantly updated with the relative altitude. It seemed like something that might take an hour or two max. However, with the incomplete solutions available and cryptic problems with refreshing the display while in a closure, it became much harder than I ever anticipated.

Which is why I’m publishing the code, however amateur, because it does actually work.

Coming up in February 2016 I’ll be facilitating the Agile Architecture game with my former colleague and game inventor Kevin Matheny. We’ve used the Agile Architecture game within BestBuy.com to help project managers, business analysts, product managers, engineers, and others learn about the tradeoffs involved with long term software architecture choices. It’s a fast way to learn about the hard choices that architects make every day.

One of the comments from a person at Best Buy that played the game was “It felt like work.” This person was an architect so we felt like we got the game right.

Tech Cities 2016 is a conference sponsored by the Carlson School of Business to foster the vision of Minneapolis being the tech center of the North.

Best Buy had a recruiting booth at the conference and hopefully you had a chance to stop by and chat either with a recruiter or an engineer. If not check out the BestBuy.com jobs located here.

I had a chance to give a new presentation on how and why engineers should be engineering managers, at least a few of them. If we ever want more great places for engineers to live and work, someone needs to create them. Only individuals that understand how software engineering really works can create those places. Here’s a picture from the conference.

If you couldn’t make it this year, put it on your calendar for next year.

Sometimes I think I studied the wrong field in college, I should have been a political scientist or a historian. Having studied in those fields it may have helped me understand that the worst thing that can happen to a revolutionary is to win the war and end up governing.

A true revolutionary is not doing what they do because they are seeking power, they are championing an idea, a culture or a different way of life. They believe it; to the point where they’ll risk their lives in a real war, or their professional career if they work in a corporation. We’ll stick to corporate revolutionaries for now, it’s a little bit safer.

The thing to remember is that most revolutions fail, which is great because the corporate revolutionary can move on to the next place with their ideals intact and their pride unblemished. They haven’t had to face real decisions that would affect how they view themselves and their core beliefs.

But what if the unthinkable happens and the revolution succeeds? Now you’ve got a bunch of idealistic, stubborn, socially awkward and politically unsavvy people running your organization. No one wants that, you’ll be replaced by “real managers” the second you make a big mistake.

First, believe that a powerful force is waiting on the sidelines to determine whether the result of the revolution is a new paradigm that improves the old, or a purveyor of ideals that must be snuffed out quickly lest they infect the entire organization. As the new governing body, you need to exude ineptitude while clandestinely shoring up political position and making some new friends of old enemies. Once you’ve established a culture and moved systems beyond the point of no return, you can show your true hand, your competency, and institute the revolutionary ideals that were the driver of all the change.

This is where reality sets in. Running a revolution and governing a semi-stable organization are two distinct beasts. In revolutionary times, it’s us against them, there’s always a big enemy out there to drive camaraderie and take the brunt of negative emotions as they crop up. However, once the enemy is gone, the emotions turn inwards and now you are left arbitrating disagreements between former allies and making decision you know are bad, but are necessary to prevent chaos.

The skills of the revolution are not the skills of maintaining and building incrementally on top of established practices. If you cannot make the shift to sustaining governance, everything you fought for will eventually collapse and regress to the mean. Temperance, consensus, collaboration, compromise are all words that would cause the revolution to fail, but are necessary to sustain the new system over time. Operating in the same environment for multiple years is massively more difficult than moving to new gig every year. It is also massively more rewarding to see a system build, grow and become the new normal. After five years it is firmly in place and no longer can be replaced, that is, until the next revolutionary comes along…

What does it mean to start an open source project internal to an organization? Does that make any sense?

Many large organizations have very large systems within them, systems which are mission critical to the delivery of their business model. These systems are often bottlenecks for development as, in some fashion, they cannot be avoided and some development work is needed to complete any enterprise scale capability. They limit the change available to an organization.

What if there were a way to unlock the capacity limit on these systems? There is, open source the project.

If you open source a project internal to a company you are opening up the codebase for anyone in the company to work on. Instead of supplying a dedicated development team, you now need a dedicated team of system stewards, people that ensure the stability of the system and that the code being added meets the criteria of the project’s sponsors.

You can now do this fairly easily with Git based source control, where anyone in the company could write a module or patch and submit a pull request. The stewards review the pull request and whether the code takes them in the direction of their roadmap for the project and potentially accept the request into the main repo.

If done correctly you’ve opened up the system to the teams with the greatest need, while still maintaining control over the system and its direction. If done incorrectly you’ll probably have the biggest mess of your life. To push an entire enterprise forward at higher velocity the risk may be worth it.

This may be a bit self-promotional (but then it is a blog) but I made it into the library! Wow, you say. Well let’s step back to childhood and growing up in an academic family where the measure of worth was not just how many Bachelors degrees a person had, that was small potatoes, but how many PhDs, law or medicine degrees a person had. In my extended family, two or more was the norm.

So imagine the horror when I dropped out of the PhD program for Nuclear Fusion at the University of Wisconsin. Yes, I am a failure at life.

Fast forward 20 years or so and I just wrote an article for IEEE Software magazine. When I was writing it I didn’t realize that IEEE Software is one of those journals that appears in libraries in Universities around the world. However, I discovered that today! I have an actual citation! I’ve finally done something the family can be proud of!

I was discussing art with my daughter, someone who is extremely talented at what most people consider art. That is, being able to draw and paint things that look amazing and you know you could never do yourself, not in a million years.

In any case, she made the comment that all artists hate their work. This is an intriguing statement because if it were true than there is no incentive to actually make art. If you know you’ll hate it what’s the point. With further questioning we clarified that the statement really means an artist is never happy with the outcome. This is far more reasonable, nothing ever turns out like the perfect image you have in your head for how something should be. Try as you might, you know if you could just figure out how to get there, the piece would be infinitely better.

Now this makes sense to those of us who work on large dynamic constantly changing systems. Systems that are constantly under varying stressors such as high volumes of traffic appearing in ways that were not anticipated, frequent code releases that can cause unintended consequences, and the connection to numerous other systems that often go awry.

All of these things are done in code, and we all know that if we could just puzzle it out, there’s a better way to construct this system; something which is eminently simple. Maybe we’re using Tinker Toys when we should be using Lincoln Logs. There’s a seismic shift that can happen if we could just force our brains to make a jump, we can often feel it out there waiting to be discovered. But the reality of having a job and a deadline kick in and we have to deliver something that works. Perfection not achieved, again.

When writing code you get used to this feeling because you are delivering every day, often on a long timeline and things just have to get done, sometimes badly. We’re not happy about it but the world moves on.

Looking back at the large systems you’ve built you can always point out the things you wish you could change. Sometimes you get the opportunity to refactor them, possibly finding out the idealized new architecture actually was worse than the original system. Sometimes your amazing ideas fall down when confronted with the complexity inherent in large systems. However, sometimes the new system is fantastic, there’s just some things that could still be better…

It is hard to love the outcome, it’s the child that rebelled and ran away from home after stealing all your money and taking your car.

Creating large systems is essentially a form of art. There’s no defined methods to ensure a positive outcome. For works like www.bestbuy.com, the work is in the public domain and constantly being judged by individuals and the media. Some people love it, some hate it, but everyone has an opinion. And, finally, you can sell it (well technically the company could sell it).

One interesting phenomena we’ve noticed on long running projects and teams (> 1 year), is that when we take the same people and make new mini teams to attack certain problems the results are suddenly better. The results seem to last as the team is disbanded and the individuals return to their previous roles, they suddenly have different ideas and a better overall view of the problems faced by their peers.

This has obviously been done for ages with “tiger” teams and secret task forces. However, it got me thinking about a different way to manage agile software development at large scale. Instead of creating 5 or 10 small teams with 6 or 8 people and managing a backlog over the course of years, you could take the same set of people and continually reconfigure teams to address a set of stories or defined epics. Thus, the teams would always be changing and no one could fall back into a comfort zone of a known set of people and interactions. I envision it as an extension to the idea of constantly switching pairs, only this time constantly switching up entire teams.

This likely sounds like hell to a certain set of people that value stability and the pride of working for long periods of time and knowing a certain area of software extremely well. There is also another set of engineers that would jump at the chance to continually be building new things with new people. Trying to find the healthy balance is the key.

Some new potential benefits would be that engineers are forced to build as simply as possible, knowing that new people would be picking up their code within weeks rather than years. It would also force more communication and a better understanding of the entire system on all participants.

I’m afraid to try this as I can also see it devolving into a giant mess where everyone is unhappy. It is also difficult to change up teams that have been together for a year and are hitting a serious stride in productivity. Studies on teams show that those teams that are together longer get more productive so this may be a terrible idea.

Still, the focus and discipline that comes from a small team knowing they only have two or three weeks/months to get a fixed set of work done has tremendous value. We’ll have to experiment with this a little more before taking it further.