Archive of articles classified as' "rant"

Back home

There is no essence of Agile

30/05/2014

real agile is: talk to the users directly, know their pain point, address it, repeat. -someone on Twitter who I disagree with

In many conversations about Agile, especially as of late, I read something like the above tweet. I don’t know where the idea that Agile can be distilled down into one or two practices or principles comes from. Thinking this way is extremely harmful. If you think like this, I’d love to hear your explanation.

Agile methodologies come out of Lean thinking which comes out of the Toyota Production System (TPS). The TPS is incredible. It mixes explicit practices such as 5S, ideals such as JIT, and principles such as “respect for people” into a unified, harmonious way. TPS is often represented using a house metaphor as in the following image:

house-of-lean1

The house is an apt metaphor because every single component is structurally vital. “Talking to users” and “addressing pain points” corresponds pretty closely to “customer satisfaction,” which is the roof of the TPS house. The roof is elevated by the walls, which are secured by the foundation. The roof is integral to the function of a house, but no more so than any other component. Customers can only help inform what you produce. If you are unable to produce those things at high quality, speed, and efficiency, and improve over time, then it doesn’t matter how much you talk to customers.

Adding an Andon cord to an assembly line does not make a manufacturer Lean. Being Lean requires a whole set of practices, ideals, and principles working in unison. It can be TPS, or your adaptation, but it requires incredible rigor, skill, and learning, and it’s not simple. Likewise, no single practice, from TDD to iterations to talking to users, creates a well-performing Agile organization.

There are plenty of pseudo-Lean companies, just like there are plenty of pseudo-Agile shops. On the plus side, the damage from Six Sigma Black Belts is far more severe than the Certified Scrum Master racket.

Companies that are Lean are rare, and have been at it for a while. It’s silly that every JIRA jockey thinks they have learned the essence of Agile. Being Agile is difficult, complicated, and takes a while. Let’s not try and distill it down so much that we totally dilute it.

5 Comments

Adjustable standing desks should be mandatory

26/05/2014

At CCP’s Iceland office, everyone’s desk is able to adjust into a sitting or standing position. I don’t know who decided this perk. It must have been a huge expense. Adjustable sit/stand desks are already expensive in the USA, and in Iceland I’m sure they were three to five times more expensive. Until recently I thought it was required by law! This is quite an investment for each worker, but in my opinion, well worth it for a wide variety of reasons, from health to programming. Why?

  • Lots of people want to try a standing desk but don’t want to be “that guy” who asks for an expensive piece of equipment but doesn’t use it. Having an adjustable desk by default removes barriers to entry.
  • Seeing people stand (and talk about how much better it is) becomes viral. I watched it catch on at work over a few years to where everyone in certain areas is doing it. This wouldn’t have been possible without everyone already having adjustable desks.
  • Standing for part of the day completely fixed my sciatica (lower back/hip/butt pain). It also apparently has lots of other health benefits.

Okay, but “health of your workers” is a pretty nebulous concept, and in America, a business’ job is to make money for shareholders, not, like, improve society! Why would Donald Sterling want to buy black employees adjustable desks in addition to cars and houses?

  • It helped me concentrate. I was able to work faster while standing. Standing is time for working. I don’t know if this is universal, but I certainly didn’t see many people playing games or getting lost in a “YouTube hole” (as a friend puts it) while standing.
  • Pair programming and over-the-shoulder reviews were incredibly more effective while standing, even with people of different heights. Standing, I could pair easily with pretty much anyone, from a good friend to an interviewee. I was able to mentor far more effectively since standing felt like such a more natural way to collaborate.
  • Even if you don’t like pair programming (have you tried pairing while standing?), being able to program and edit code collaboratively during a code review is, IMO, a requirement. Standing code reviews were more effective than sitting. More issues got uncovered and more knowledge was transferred.

How do I know all these things? Well, when I transferred to the Atlanta office, I no longer had an adjustable desk (or a sensible healthcare system, but that’s another matter). Suddenly, reviews with people I was very comfortable with and worked with previously felt rushed and unpleasant. They were done while leaning over (“when can I get my crotch out of this other person’s face“), or sitting together (“oh god we keep brushing knees“).

Pair programming, which is the foundation of the way I mentor (and learn), was basically ineffective. No one programs well at an angle to the monitor, and people mistype constantly if the keyboard is not in a natural spot. It’s difficult to share knowledge or equipment in such an awkward situation.

If you want a vibrant and dynamic engineering culture, standing desks are a must. I view them as fundamental to a programming team as decent workstations and SSDs.


Real studies about adjustable desks are difficult to find. This 538 analysis is promising: http://fivethirtyeight.com/features/i-stand-corrected-about-the-best-kind-of-desk/. Otherwise, it is very easy to find endless anecdotes about the usefulness of adjustable desks. Start with the 538 article’s comments if you don’t know anyone!

5 Comments

The myth of the brilliant jerk

21/05/2014

Do not tolerate brilliant jerks. The cost to teamwork is too high. – Reed Hastings, Netflix CEO

So I was all prepared to write about how much I hate this quote, but Freddy Nager already did. It is thorough and insightful and explains how out of context this quote is. Thanks to Freddy for doing a far better job ripping this apart than I did. (It also reminds me the difference between real writers/bloggers and people who just have a blog, like me…) Here’s his conclusion, but I suggest you read the whole thing:

In short, Netflix wants only stars who are passionate and courageous and innovative and always do A-level work while abhorring process and questioning assumptions yet working as a team — otherwise they get fired. Sounds brilliant. And jerky.

Why is the Hastings quote so popular? The Netflix presentation is a really excellent one and full of interesting advice and strong statements. I’d even say the brilliant jerk of corporate culture presentations! Why does this quip about “brilliant jerks” resonate with people so much? Probably because we’ve all run into the “brilliant jerk” and the idea of just firing him or her is so pleasing. It also remains cowardly.

This hits particularly close to home for me because I have seen the mistreatment of far too many brilliant jerks. Brilliant jerks are necessary to grow and innovate. The difficult part is to figure out how they can be brilliant but be less jerky.

Firing brilliant jerks is the absolute worst thing to do for teamwork, or indeed the health of the company as a whole. I could spend more time convincing you, or you could view the Netflix slideshow that spawned the quote!

2 Comments

An Unfoolish Consistency: Introducing PEP8 to a legacy codebase

25/04/2014

Consistency with this style guide is important. Consistency within a project is more important. Consistency within one module or function is most important.

The EVE source code, being initially developed before PEP8 existed, was based on Microsoft’s C++ style. Mostly this is manifested in UpperCamelCase function and method names, mixedCase parameter and variable names, and file headers and class/method delimiters. There was also a style guide that was probably larger than PEP8 (though included a bit more than basic style).

Today, most new code is PEP8 compliant. “What!?” I hear you say. “A foolish consistency is the hobgoblin of little minds!” I agree, and I’ll get back to that at the end. But first, what was involved in introducing PEP8?

The move started when I asked my team if anyone wanted to keep using the headers and delimiters. No one did. So we took out the headers and delimiters before we did any modifications to a file.

A while later, I asked all the programmers on the project if anyone felt strongly about keeping the existing style. No one did. So we started writing new packages with PEP8. The rationale was that our code was already calling code using lowercase_underscore in the stdlib, so it’d be no different for that same code to call a relatively independent, though still project-related, library.

Yet a while later, I started slipping some PEP8 code into modules or packages that weren’t PEP8. I was worried people would get upset. No one did.

And finally, in preparing some basic utility libraries for usage on other projects, I converted the function and method names to PEP8. This involved find-and-replace or CamelCase aliases. I bet you can guess who cared about these “superfluous” edits, or objected to the fact that parameter and variable names remained mixedCase? No one did.

Emerson’s quote “a foolish consistency is the hobgoblin of little minds” is often used as a reason to not change existing code to PEP8, or introduce it into a non-PEP8 codebase. But the quote means the opposite. Foolish consistency” is being unable to change your mind because it would contradict something you’ve believed or said. So PEP8 has it so right but so wrong: the foolish consistency is to keep things the way they are, even though we know what the right thing to do is.*


* I would recommend introducing PEP8 incrementally. I also suggest keeping things backwards compatible when it is more prudent, such as if the changes are expansive, or you do not control all the code. I also don’t suggest being a stylistic nitpicker when it comes to non-functional aspects such as line length. There may also be times to break the rules (a class that behaves like a function, or function that behaves like a class def). As always, good sense should be applied when considering any viewpoints on this blog.

No Comments

The “Year of Code” Director is Your Boss

12/04/2014

There was some hubbub a few months ago when it was revealed the Executive Director of the UK’s Year of Code initiative can’t code [link]. Not that technical (domain) competency is a sufficient condition for management and leadership, but I’d certainly call it a necessary condition. (I’ll use the world ‘technical’ below to refer to any sort of specialized domain, not just programming.)

Apparently a number of people don’t agree with the idea that competency in a domain is a requirement to manage that domain.* I find this idea infuriating and it can only end poorly.

Perhaps you have a manager who knows little about programming or design or whatever your specialty is, and you consider this person to be the best boss of all time. Great! I’ll call this person Your Boss for convenience. Here’s the problem:

At some point, Your Boss needs to make some contentious decisions. Maybe over your work, maybe over something you’re not directly involved with (I bet Your Boss was hated by a lot of people, too!). Your Boss has literally no ability to help resolve a technical decision. “Wait!” I hear you say. “My Boss is enlightened enough to know that the people closer to the problem should be making the decision!

But who are those people closer to the problem? Who put them there? Oh, that’s right: Your Boss. But your boss has little technical knowledge. How is Your Boss supposed to decide who makes the more technical decisions? Without basic technical ability, Your Boss doesn’t even know what questions to ask. Your Boss can’t even learn; she doesn’t have the technical prerequisites. Instead of being able to provide leadership, Your Boss is left scratching her head. This is not leadership, and this is not management. This is a cancer and an organization that is unable to grow and learn.

It’s no surprise this topic is divisive. When Your Boss places a lot of trust in you, you are autonomous and think of Your Boss as the best boss of all time. But when someone runs up against you and Your Boss, they have no real recourse, because Your Boss trusts you and has no ability to further inspect the situation.

Certainly, superior ability or experience is not a requirement for management over a domain. But I thoroughly believe that not just familiarity, but some actual professional practice, with a domain is a requirement. I hope that if you are someone who believes in the myth of the competent non-technical manager, you’ll rethink your experience and view Your Boss in a more complete light.


* Clearly, at some point, you cannot be experienced in all the domains you manage, and need to trust people. Unfortunately we do this far to soon, and accept a development manager who has not developed, or an engineering manager who has not done much programming. In the case of the Year of Code Director, I think the issue is a non-technical background (in programming nor teaching) and a general lack of experience. If she had proven a wunderkind in her given field (which is, btw, basically PR/marketing/communications), maybe she should be given the benefit of the doubt. There are many examples where talented administrators have moved into new areas and been quite successful. But her appointment, along with most of the rest of the board, is pretty clear cronyism (and when you throw out technical merit and domain experience, you’re left pretty much with cronyism).

3 Comments

Why Agile became meaningless

6/04/2014

Uncle Bob recently wrote a post about The True Corruption of Agile. I think it will be a defining post for me because, as I’ll explain in my next post, I’m ready to give up on Agile. It has become meaningless due to the corruption Uncle Bob describes, and trying to reclaim Agile isn’t possible.

Imagine the Lean movement without Toyota. Toyota is the guiding force in Lean because it grew out the The Toyota Way.* When Lean goes awry, Toyota- the company and its principles, practices, and culture- is there to set things straight.

Toyota can guide Lean because the company has been successful for decades and Toyota attributes its success to the principles and practices known as The Toyota Way. But for many years, Toyota’s success was explained away by anything except the Toyota principles. Finally, all that was left was The Toyota Way. Toyota is the Lean reference implementation.

Agile has no such entity. Instead, we have hundreds of “Agile” shops who attribute success to some (non-)Agile practices. Then, once they’ve evangelized their (non-)Agile stories, reality catches up with them and the success disappears.** But no one hears anything about that failure. The corruption and perversion here is inevitable.

Without a company like Toyota giving birth to Agile and showing others how to do it right, Agile was destined to become what it is now: meaningless and corrupt.


*: The Toyota Way started out as the Toyota Production System. They aren’t technically the same but for the purposes of this post there’s no reason to distinguish.

**: For example, maybe InnoTech decides to use Scrum on a global scale to ship an ambitious product, and talks a lot about how they pulled this off and what benefits it yielded. Years later, velocity is in the toilet because the endless mountains of technical debt created, and maybe the company has had layoffs. The Scrum transformation will be in a book or on a stage. The layoffs or technical debt will not.

1 Comment

What does your Product Owner own?

3/04/2014

In a previous post, I came down hard on Agile leaders that don’t program. Now I’ll turn my sights to another part of the Scrum trinity: the Product Owner. I’ll raise some concerns for what I’ve seen it become in videogames, and suggestions for improving how we use the role.

Most product owners I’ve seen in the videogame industry are much closer to project managers than business owners. Their primary job is often the coordination, planning, and prioritization of the cross-team dependencies that the scaled-up nature of game development tends to create. I’ve seen designers and business/marketing in the PO role on occasion. It has sometimes gone very poorly.

I’ve always thought this situation strange, as the PO role most closely aligns with someone from the discipline of game design. We usually don’t have a problem with mapping a Creative Director or other core vision holder to the role of PO. After all, they are the product champion, and marry game design and business sense. A project manager clearly wouldn’t suffice here. But then other POs on the same project are all project managers. What gives?

There’s are some litmus tests for seeing how product ownership works in your organization.:

  • Do people “graduate” from Scrum Master to Product Owner?
  • Do the same people occupy both Scrum Master and Product Owner roles, concurrently or not?
  • Is your product owner leading and championing, or following orders (from above and from the team) and focused on execution (metrics, tracking)?

The skills between product owner and project manager are significantly different. There’s a problem if most people are seen as able to do both, and if POs aren’t coming primarily from design, business, and marketing.

There are lots of reasons things get this way. The important thing is to realize that the term PO isn’t a good fit for what most POs are doing. I see two options.

The first option is to commit to a Chief Product Owner/Area Product Owners structure (described in the footnotes*). Here, product ownership is seen as a distinct set of skills that bridge the business and design/creative side of development. If you have the right people (for example, POs for the overall/creative, technological, visual, and operational parts of the product), this can work quite well. I’d say this is a much better option, but frankly can be difficult or impossible to pull off if you do not have the right people or mindset.

The second option is to commit to having a single Product Owner, and having a project manager (Producer) on each team who is responsible for traditional project management duties and being a proxy for the real PO. They make few decisions of their own, but just act as dutiful middlemen. Usually the Producer will also take the role of Scrum Master, though I think this is a shame as their focus will be on traditional project management. This will make it difficult to make sure your teams are getting an ongoing Lean and Agile education.

Ultimately, the key is to acknowledge how product ownership in your organization works. If how people are fulfilling the role of PO does not seem to align with the literature, change something. You can choose option one, and change your organization to match the literature. Or you can choose option two, to abandon the literature, and find something that will work instead. In either case, do not continue the dissonance.

The core of Lean and Agile is continual improvement. If you are using confusing or inappropriate terms and organizational structures, you sow confusion. If you are confused and without direction, you cannot reliably improve.


*: Scaling Lean and Agile Development is the best book I’ve read about scaling Agile development methodologies. Regarding the role of the product owner, their recommendation is to have a single PO if possible, but to have a single Chief Product Owner and several Area Product Owners if one PO is impractical (which it often is in game development). Importantly, POs are tied to areas of the product, and not to teams (who can and should drift between areas of the product).

4 Comments

Mike Bland’s profound analysis of the Apple SSL bug

1/04/2014

Mike Bland has done a series of articles and presentations about the Apple SSL bug over on his blog. To be frank, it’s pretty much the only good coverage of the bug I’ve seen. He’s submitted an article to the ACM; crossing my fingers it gets printed, because it’s an excellent analysis. I’ve been frustrated it hasn’t gotten more traction.

Mike’s take is that this bug could have easily been caught with simple unit testing. It’s sad this has been so overlooked. We gobble up the explanations that do not force us to confront our bad habits. We can point and laugh at the goto fail (“hahaha, never use goto!”), or just shrug at the merge fail (“we’ve all mistakes merging”). It’s much more difficult to wrestle with the fact that this error- like most- is because we are lazy about duplicating code and writing tests.

I have no problem categorically saying anyone who doesn’t blame the SSL bug on lack of automated testing and engineering rigor is making excuses. Not for Apple but for his or herself.

No Comments

What if Carl Sagan were a hack?

31/03/2014

I was watching the first episode of Cosmos, and Neil deGrasse Tyson talked some about how stellar of a scientists Carl Sagan was and what an impact Carl had on Neil personally. Carl’s abilities were important for his advocacy, because a) it lent him credibility, and b) it allowed him to engage. He practiced while he advocated. I can’t imagine Carl Sagan achieving the impact and legacy he did by abandoning the lab for the lecture circuit.

What a powerful lesson for those of us that manage people doing work we’ve never done. How can we deeply connect with them?

What a reminder for those of us that have moved into managing and left behind creating. Should our dues, once paid, last forever?

What a feeling for those of us who have moved into management out of expectation. Is it right to tell people what to do, while we have lost enough passion to do it ourselves?

2 Comments

Why I love blogging

29/03/2014

I started to write a post about how I missed multithreading and speed going from C# to Python. I ended up realizing the service we built which inspired the post was poorly designed and took far more effort than it should have. The speed and multithreading of C# made it easier to come up with an inferior design.

The service needed to be super fast, but the legacy usage pattern was the problem. It needed to run as a service, but then we realize it’ll be running as a normal process. This is what happens when you focus too much on requirements and architecture instead of delivering value quickly. You create waste.

I wouldn’t have realized all of this if I didn’t sit down to write about it.

No Comments