Every week, I have to use six different Office Software Suites:
As an expert computer user (former SysAdmin), I’m often asked for help by people with non-computing backgrounds. When they see how many different suites I’m using, they’re … surprised, to say the least. Here’s a quick snapshot of what and why.
TL;DR: experienced CEO/CTO/TechDirector with long background in programming, sales, and business management (Corporate, iPhone/Android, Games, Education) looking for strategic roles in USA, UK, and Asia.
After a year-out to do a post-graduate degree in Education, I’m looking for something new and exciting to do next. My primary goal is to boost a company or team rapidly and show significant outcomes – increased revenue or other KPI’s – either through Consulting or full/part-time senior leadership.
Ask 10 game developers if you should use more script code or less, and you will get 11 different answers. They are all correct: it’s very situation-specific. Use of scripting languages is highly dependent on the humans and the practical / project-management issues.
Why?
I maintain a medium-sized open-source project. I welcome bugs and ideas via GitHub’s excellent “Issues” tab.
Some Issues are well-written, others are not. Strangely: Issues get resolved fastest are often the shortest – as little as 2 or 3 sentences. Doing it “right” is easier than I expected…
Let’s be honest: many games-industry teams/studios abuse Scrum. Then, after months of pain and suffering (and poor project-progress), the team members go to other teams or companies, and take a hatred of Scrum/Agile with them.
So it’s interesting to hear from people who’ve made the transition from “Agile/Scrum done wrong” to “Agile/Scrum done right”.
Quotes I’ve heard repeatedly:
This came up on a forum today, and one of the posters chimed-in with their own experiences. The forum’s private, so I can’t link to it, but I’m reposting their summary (with permission):
“I’ve done scrum/agile 4 times in games.
Work does 3 week sprints and is now split into 2 teams so we have 2 scrums a day. Time of this is strict, on-time and 15 mins long*.
Our Producer/Product Manager only sees the program in the Sprint meeting. The entire team is in the Sprint meeting also, which is now pretty good. The Sprint meeting lasts the whole day. So that’s 6-8 hours every 3 weeks*.
The morning is broken into what we did in the previous Sprint. We demonstrate each story and if we tick all the requirements defined in the story it gets marked as complete. If we don’t complete it, we say why and a new story gets made with what’s left. This is only if it is still required and may be put into the Backlog and done several Sprints later.
The afternoon is spent deciding on the next stories. These have been defined by: the Customer Requirements/Publisher/Whatever, the Producer and the Leads. The 2 teams break off and the whole of that team decides the requirements AND the time it will take. This prevents the wasters on the team getting away with poorly defined requirements and giving a time that is clearly taking the piss*. It also covers people underestimating. The peer-pressure means people work because next Sprint people have to explain why it wasn’t finished when everyone decided on it. If no one can decide on the time then it clearly hasn’t been defined well enough*. It helps because the team works closely together and they all understand those parts.
We can ask the Product Manager questions at any time etc, but like I said: he never sees the work in progress for 3 weeks. He also never comes in and changes things*. Because it’s the whole team plus the Producer/Product Manager agreeing on things, features gets dropped when needed, priorities get sorted, and blame can be removed from the development cycle*.
There are various other small details but that’s the main bit of it.
If you aren’t doing these things in scrum/agile then really you’re just wasting people’s time and giving waterfall development the wrong name.
* All stuff Game Development scrum failed to do in my experience.”
In the past, I’ve found Thomas’s Kickstarter analysis for game-projects very useful. Today I found something that complements them: an excellent visualization of Kickstarter projects.
It takes a little thought to understand how to use it, so here’s some ultra-quick example analysis…
I just ran into a 2004 piece of FREE software that I wanted to use, but can’t, because of poor choices by the original author. I’m posting this because I think the ideological reasons behind those choices are now “of historical interest only” and I’m liable to forget them completely a few years from now – but the underlying issues remain.
Especially in a world where Android, on a marketing platform of “openness”, is competing with iPhone, on a platform of “all users are lazy or idiots”.
(As a user, I hate being treated like an idiot. Except when it means a computer does all the work for me. Fair? Reasonable? Nope! When it comes to users … developers can’t win :) )
There used to be a raging debate, for decades, about the “correct” way to distribute applications. A bunch of well-meaning (but IMHO un-wise) Open Source programmers advocated:
“The only way to distribute a program … is as raw Source Code”
This was not about “is Open Source good?” – this was *in addition to* making source available. The question was: should you send people a copy of the source – or should you compile / package binaries (one-click applications) for people to download and “just run”?
The debate seems to be dead (finally), with the world coming down on the side of practicality, rather than theory/ideology. I’m not entirely happy with that – but it always felt obvious to me that it would go that way. I think the App Store in particular has gone a long way to “proving” it once and for all: people who want apps … want apps. They don’t want source code. Even if having the source would sometimes help.
Today I ran into a tool that concretely demonstrates the futility of the “only source code is correct” argument: SLOCcount
The project as it stands is unusable unless you happen to be running one of the two linux distros where people have built the binary – or you’re willing to waste anything from “hours” to “days” of time “configuring” the app.
(with a normal app, that “hours of time” is replaced by “0.1 seconds it takes to double-click the app icon”)
This is a simple command-line tool. To run it, you must:
No wonder people don’t use it. No wonder people don’t update it, even though it’s “Open Source”. No wonder this – otherwise useful tool – is effectively dead.
OK, so the straw-man example above mainly comes down to:
“make” is the world’s worst configuration tool
SLOCcount was probably killed by the choice of bad tools, as much as anything else. But – how much choice did the author have, really?
The problem is – and this is the interesting point of this blog post:
(in general) Source Code does not fully describe a program; it merely describes “SOME OF the internals of a program”
To create an actual usable program you need something like (off the top of my head, I think this is correct?):
…where the final output of step 7 is collectively known as “an application” (or just “an app”).
The folks who used to argue that all code should be distributed as Source tended to use arguments about the “value” of Source Code, as if it were a valid substitute for all the above items. It was never a *substitute*, although getting the output AND the Source would have been better than the tradition of only receiving the output.
Of course, even better would have been: receive all 8 items above (all the things necessary to make the app, and the app itself).
And so … if you’ve ever wondered what’s inside package-management sytems … take that list of 7 items above, and go revisit your favourite system of choice.
And … bear in mind that all the above things can have complex version dependencies – e.g. “only works with library A, version greater than 2.3, but less than 2.6, or with library Aa version 7.99 exactly”. A package-manager has rather a lot to handle…
Steve Yegge’s Google Platforms Rant is not so much a rant as a sign of someone fighting an inappropriate culture. We saw stuff like this a lot at NCsoft when people were trying to turn around the $100 million clusterf*ck that created hundreds of redundancies all the way to director level.
It’s a great article, but a couple of the key points resonated with my own experience of Google UK’s hiring practices a couple of years ago. There was clearly a lot wrong with the internal culture, but as an outsider I couldn’t quite put my finger on it. Here’s the crux of Steve’s post (but seriously – read the whole thing, it’s rich and meaty):
That one last thing that Google doesn’t do well is Platforms. We don’t understand platforms. We don’t “get” platforms. Some of you do, but you are the minority. This has become painfully clear to me over the past six years. I was kind of hoping that competitive pressure from Microsoft and Amazon and more recently Facebook would make us wake up collectively and start doing universal services. Not in some sort of ad-hoc, half-assed way, but in more or less the same way Amazon did it: all at once, for real, no cheating, and treating it as our top priority from now on.
But no. No, it’s like our tenth or eleventh priority. Or fifteenth, I don’t know. It’s pretty low. There are a few teams who treat the idea very seriously, but most teams either don’t think about it all, ever, or only a small percentage of them think about it in a very small way.
It’s a big stretch even to get most teams to offer a stubby service to get programmatic access to their data and computations. Most of them think they’re building products. And a stubby service is a pretty pathetic service. Go back and look at that partial list of learnings from Amazon, and tell me which ones Stubby gives you out of the box. As far as I’m concerned, it’s none of them. Stubby’s great, but it’s like parts when you need a car.
…and finally, reading that, it clicked for me what I saw that was so wrong:
“It’s a big stretch even to get most teams to offer a stubby service to get programmatic access to their data and computations. Most of them think they’re building products.”
That pair of sentences, back to back, is the problem: people outside Google would put the word “except” in between. Googlers put the word “because” in between. Google’s cultural definition of Product has got lost and perverted somewhere along the way, and now looks and smells like the real thing but is – to the rest of the world – a fake. Except Google – internally – can’t see this.
Every Googler I talked to worshipped at the altar of Product-as-King; three quarters of them would then – even in the same sentence – admit that they hated Product, didn’t believe in it, and felt it was a waste of time — “get out of my face with your product BS, and let me write beautiful code in my Ivory Towers, and leave me alone”.
They were smart people; they never said this explicitly (although one came very close – and you could see the moment when he had the thought: “oh crap; if anyone else hears I said that…”, then backtracked very hastily) – instead they frequently said mutually conflicting things, and dressed them up in enough abstractions that you could pretend that they weren’t conflicting. They were very good at it – I could tell there was a crack, but I couldn’t work out where the fault-line lay.
As Steve puts it later on:
Google+ is a prime example of our complete failure to understand platforms from the very highest levels of executive leadership (hi Larry, Sergey, Eric, Vic, howdy howdy) down to the very lowest leaf workers (hey yo). We all don’t get it. The Golden Rule of platforms is that you Eat Your Own Dogfood. The Google+ platform is a pathetic afterthought. We had no API at all at launch, and last I checked, we had one measly API call. One of the team members marched in and told me about it when they launched, and I asked: “So is it the Stalker API?” She got all glum and said “Yeah.” I mean, I was joking, but no… the only API call we offer is to get someone’s stream. So I guess the joke was on me.
Product. Platform. Since when have those been mutually exclusive? Not in this Millennium, I believe…
And even when Google gets over their hatred of Platform, even with something as simple as the pixels that their apps put on screen, they’ve jumped the shark:
You know how people are always saying Google is arrogant? I’m a Googler, so I get as irritated as you do when people say that. We’re not arrogant, by and large.
But when we take the stance that we know how to design the perfect product for everyone, and believe you me, I hear that a lot, then we’re being fools. You can attribute it to arrogance, or naivete, or whatever — it doesn’t matter in the end, because it’s foolishness. There IS no perfect product for everyone.
And so we wind up with a browser that doesn’t let you set the default font size. Talk about an affront to Accessibility. I mean, as I get older I’m actually going blind. For real. I’ve been nearsighted all my life, and once you hit 40 years old you stop being able to see things up close. So font selection becomes this life-or-death thing: it can lock you out of the product completely. But the Chrome team is flat-out arrogant here: they want to build a zero-configuration product, and they’re quite brazen about it, and Fuck You if you’re blind or deaf or whatever. Hit Ctrl-+ on every single page visit for the rest of your life.
It’s not just them. It’s everyone.
Any genuine Product person would run screaming from that situation – there’s nothing salvageable. It’s like someone coming to you with their design for a chocolate teapot: “Once you’ve had your tea, you can have a tasty chocolate treat too!”, leaving you wondering: where do I even start with trying to explain to this person what they’re missing?
With Scrum, you’re constantly focussing on:
How does the application look / work for the user *right now*?
…to the extent that you care more about “does this feature work for the user?” than “is the code/art/architecture for this feature ideal?”.
We regularly get situations where a feature *appears* to work, to a casual observer – but on deeper inspection, it’s clearly broken in one or more significant ways. Sometimes, the “broken” parts are so obscure that you’d need help to even find them. Other times, they’re obvious if you try to to use the feature more than just once or twice.
In Scrum terms, it’s pretty clear what’s gone wrong: the Product Owner didn’t describe the feature clearly enough (they implicitly included functionality they didn’t really care about, … or they described it too vaguely to be implemented well).
Scrum’s in-built check/balance against that is the Team. The developer who adopted the task should have rejected it during the Planning meeting, should have insisted on a clearer User Story (or a more explicit feature description).
But in the real world, this stuff happens. Leaving the issue: What do you do next?
Here’s an approach I’ve been experimenting with recently.
When it happens, you split the feature description in half, re-defining one half as the part which is done + working, and the other half as the part which isn’t working. Or into 3, 4, etc – if there’s multiple “player visible” ways in which it’s not working.
This seems to work pretty well – it lets us independently prioritise “the bit we’ve already got (hence: zero extra dev cost)” and “the hard stuff that’s not working”. And quite often, we end up redesigning some other part in a way that makes the broken edge-cases no longer exist – so we never need to fix them.
…but I’m still experimenting with it. I’m sure we could do our Planning meetings better – both from the PO side (more detailed descriptions, more PO planning) and/or from the developer side (more questioning, demands for more detail).
I’ve encountered many managers who are in love with the IDEA of supporting their team, but not the REALITY.
Typical examples:
So, here’s a refreshing (if somewhat old) counter-example:
I’ve been working on a new Scrum client for ScrumManagers, Scrum Teams, and Product Owners.
We’re ready for Alpha testing now – it’s simple, fast, and a bit ugly … but we’re using it for very simple projects already.
If your team uses Scrum, and you’d be interested in trying this, please send us a quick email via the application form here (at minimum, need your email address and some info about the projects you’d be trying this on and how soon):