advocacy agile education entrepreneurship startup advice

Self deception of the Startup Founder: Paralysed decisions

This week I’m paralysed on some of my simplest decisions while happily making complex decisions quickly, and being incisive and highly effective on others. This problem occasionally crops up in my work and personal life, and it frustrates the hell out of me; I’m going to write about it here, see if it helps me find a new way forwards. Hopefully this may also help others who’ve experienced a similar problem in their own lives.

advocacy agile project management

A 1st-hand description of doing Scrum/Agile correctly (in games industry)

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:

  • “It doesn’t work”
  • “It’s a load of corporate-trainer bullsh*t”
  • “It works for industries that have no uncertainty in their design; but in games, you don’t have a spec to start with”
    • [this is depressing; it’s where Scrum shines – but people have mis-applied it so much that they’re getting the opposite result]
  • “Have you seen how easy it is to become a Certified Scrum Trainer? And how much they get paid? It’s just a big con”
    • [IMHO the ScrumAlliance has a lot to answer for, in how they’ve allowed this problem over the past 5-10 years. It seems to have been a strategy of short-term gain (more practitioners) for a long-term loss (reputation and quality of practice)]
  • “In Scrum, you have to do a 2-3 hour meeting every day, where everyone on the project gives a full status update, so we never got any work done”
    • [I’ve heard this worryingly often. It’s stunning that anyone could allow their Daily Scrum meetings to go so wrong]
  • “Scrum is all about equal authority and shared responsibility, but some (our manager) are more equal than others, and never responsible for the failures”
  • “Agile is where you can do anything you want and when someone on your team is lazy and claims everything will take 10x the actual time, so they can do no work all day … you’re not allowed to disagree. Because Agile/Scrum says you can’t disagree with each other”
    • [Again, I’ve heard this often. Did these teams accidentally read the Black Bible of Scrum? The one where everything is inverted?]

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.”

agile games industry marketing startup advice web 2.0

How middleware (and open source) downloads ought to work – Unity3D

While upgrading Unity, I noticed the current download page is a great example of how it SHOULD be done:

Unity 4 has some … issues … with backwards compatibility – but at least they made the “need an older version?” link prominent. And how many old versions can you download?


(it goes on right back to unity 3.0)

Old versions? Who cares!

Well, that backwards compatibility thing is a *****. If you work on a project with other people, and they’re using Unity 3.5 … you SHOULD NOT (must not?) use Unity 4 (there be Dragons).

But it’s fine; Unity makes it trivial for anyone joining such a project to get exactly the version they need.

Some games middleware *cough*Hansoft*cough* companies declare that everyone must use the latest version, even if it is buggy and breaks existing projects. Or if it requires staff retraining. You must retrain EVERYONE! NOW!

(Hansoft has probably changed by now – maybe unfair to single them out. But for a long time they only allowed you to download the “latest” version, and actively deleted everything else. As soon as a new version existed, BOOM! Everything else got wiped. A happy customer I was not)


So, here we have a piece of middleware, with a download page:

  • Lives at an obvious, permanent URL:
  • Makes it very easy to find the download link (many open-source projects: shame on you)
  • Uncluttered webpage, and makes it easy to understand which download you want ( shame on you)
  • Every version has its release notes right there, for you to click on! (Apple (every product), and Firefox: shame on you)
  • Every version has BOTH the windows AND the mac downloads (computers today are cheaper than they’ve ever been. Many people have a laptop thats Mac, and desktop that’s Windows, or vice versa. You can’t assume that the browser they’re using dictates the desktop they’ll be working from)

Designing a website to look simple is certainly a difficult and non-trivial task.

But in the case of a download page – where almost everyone has the same needs, and there are many examples to copy (plagiarise) from – it doesn’t take much. More projects (and companies) should at least try to do this.

agile programming

Awesome GIT client for Mac

I’ve only played with this for a few minutes, but so far it seems to have an excellent, simple, clear GUI with the core features I’d expect. Way better than any other Git client I’ve seen for Mac. And it’s free!

GitHub for Mac v1.2.1 (NB: works with any Git server, not just!)

I’ve noticed some cosmetic bugs – e.g. it renders all the user-account avatars completely wrong (puts wrong image next to each commiter) – so I’d advise “use this with caution” until you’re sure it’s got no fatal bugs. Although, since it’s from, I expect it’s pretty robust.

agile games design programming

16 KB Game Competition (winter 2011) – Java

“the LWJGL16k competition starts right here, right now.” – Cas

The rules

First deadline: 25th November 2011
First task: get a black screen running using LWJGL

“you’ve got 7 days. All I’m looking for at this stage from you is a blank window opening up and maybe a rotating square or whatever. Of course complete games are even more welcome but the idea is to get something shipped.”

Well, what are you waiting for?

If you’ve got Eclipse installed, all you need do is download the LWJGL library, copy/paste the 50-line minimal project from the Wiki, and submit your entry!

(I believe Cas is onto a good thing here … force people to realise how easy it is to make a game if you focus on small-but-visible steps done *quickly* – No more procrastination!)

agile programming project management

Scrum: I added a feature to my game, but it’s 5% broken

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?”.

“It’s not done” … “but it looks done!”

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?

One technique: Divide and Conquer

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).

agile recruiting startup advice

“I have never regretted firing anybody. Not once.” – Mark Suster

One of those things that most business people don’t talk about unless prodded. I’m not sure why, but I assume it’s one aspect of the fear “don’t burn any bridges; don’t let anyone think you can be nasty; don’t let anyone see you’re human”. None of which are healthy, long-term ideals IMHO – although they may be a good idea for many people. (they’ll often keep you in a job you’re unsuited for for longer than you would survive without them).

“I have on many occasions regretted not firing somebody quickly enough.

I’ve made every excuse to myself in the past, “I can’t fire him now, he owns the customer relationships and it’s a crucial point in our sales process.” Or, “I haven’t given him a long-enough chance to prove himself – let me see how he develops” or even, “it will have a big impact on morale because she is well liked. I can’t afford that right now.””

Some other good points in the post from Mark, including his list of 3 key ideals in hiring. Although … I still don’t agree with his “if [you change jobs] 5-6 times there is probably a pattern that isn’t completely the fault of some asshole boss.”. Well, I agree with the deduction – I’m sure there is a pattern, something interesting causing these rapid job changes – but I don’t agree with his conclusion that this is a bad sign in a jobseeker / candidate *for a startup*. (for a corporate role, it’s a huge red flag; for a startup, it might even be a positive selector; IMHO it’s too complex an issue to make catch-all pronouncements like Mark’s)

(and c.f. my previous comments on hiring, e.g.:

“I’ve noticed practically no correlation between skilled people going on to fulfil greater potential – many did, but many got worse. I’d still hire very skilled people – you know they’re useful – but … and this is a reflection of my own interests … in a startup environment, I’d tend to look for the enthusiastic ones by preference.”

agile dev-process entrepreneurship programming startup advice

Startups: how NOT to write your website sales pages

If your startup sells stuff via the internet (you have an online product, service, web-app, etc), this may be the single most important thing to get right (assuming your core idea, team, etc has inherent merit). And yet so many companies spend so much money doing it so wrong.

Why are modern software companies so bad at selling software? Today I was looking at Scrum tools (or Agile if you prefer), and I was struck by how hopeless some of their websites are. With some of these sites, I am sure that I could increase the sales of most of these companies by hundreds or thousands a year, just through basic principles of sales.

(and, obviously, HOWEVER you design your sales page, you should be using A/B testing to increase sales, conversion, etc. But A/B testing is no panacea: you still need the creativity and understanding to make the “big leaps” yourself)

Example: VersionOne

I’m going to pull out one example (by accident, the first I came across). Many others are much the same.

Before we go further, let me be clear what “kind” of customer I am. I’m currently looking for solutions for two commercial setups. One is for tiny projects on a case-by-case basis. This would be 5-seat licenses (worth up to $3000 at VersionOne’s current prices). The other is for a company-wide purchase of up to 30 licenses per annum (worth up to $15,000).

But, at the same time, my last full time job was running development for a large development studio. I was the primary reviewer and purchase-maker for software tools that were 50-person per annum immediately, and meant a commitment of up to 150 within 3 years. I’ve done a *lot* of this purchase-review process, on a lot of software.

My negative reactions to VersionOne’s sales are fairly consistent across the 3 profiles (although the reasons behind that are complex)

Landing page, from Google: the “don’t ask questions, you’re too stupid, just buy instead”, and “we love ourselves, we’re awesome” page


This has a *concealed* URL, so it pretends to be the front page, but actually lies, and redirects you to this page instead:

Ont this page, your website states it’s a commercial product, yet REFUSES to answer the single most important question: how much does this cost?

There aren’t even any LINKS to finding out about the product. It’s just “buy our product, or piss off”.

This page serves one purpose: lock the customer into a product they don’t want. You are “not allowed” to know the cost, you are only “allowed” to “signup now for a 30-day trial” – you have to commit yourself, and they’ll sting you with a price later, when you have no choice.

Word of advice: merely making something “free, for a few minutes, then I charge you” does NOT lower the customer’s barriers to purchase. For an ultra-long-term product like Project Management tools, it often has the *reverse* effect. The MINIMUM trial for a PM tool is “one project”. Most projects – using new tools – will need several months; 2 week to learn the tool, 10 weeks to run + launch + finish the project. The customer knows this; they know that a “30 day trial” is completely dishonest.

So, we use the navbar, and head to the “Product” page:

Product page: the “Want more info? Oh no you don’t! You’re too stupid, you’re just a customer!”


I’ll sum up the stupidity and smug self-satisfied attitude of the person who wrote this page with just one quote, their final bullet point in the top-section:

“Accelerate agile adoption”

[hey! Look at that! I’m so clever – three words all beginning with “a”! They’re guaranteed to buy now! I’m so sharp, sometimes I cut myself]

Sigh. Ignoring the “infographic” which has been screen-captured with a font-size of 2pts (i.e. literally physically impossible to read), we try to do something useful with this page: review the product (we’ve given up on pricing, for now – they obviously don’t wany anyone to buy the product, but maybe the product is so good we can force our way past that?)

Product page, part 2: the “we don’t trust you, we’ll spam you with marketing crap”


(below the infographic)

Just look at that page. It has literally zero information about the product, yet it’s the “product” page.

Instead, it has paragraphs of marketing crap. There’s no other term for it; let’s look at the first example.

Bullet-point: “Product Planning”

What does this mean? Absolutely nothing. BY DEFINITION, this is a whole website devoted to project-management-planning software used on projects that create products. Why do you repeat this, in such a childish gross genealization, as if it’s a “feature”?

Ah, but … actually, that’s not necessarily true. Scrum is often used on projects that are NOT generating a Product.

So, in fact, this lazy marketing title has already told some of the target-customers: “Don’t use our product. Go away”.

Let’s look at the text underneath the bullet:

“Plan and manage your requirements, epics, stories, and goals across multiple projects, products and teams.”

What is this – Why are you patronising me by telling me what you think “Product Planning” means, as an abstract concept? What kind of project manager – or engineer – is so stupid as to not know what it is they do on a day to day basis, and to feel happy that you’re telling them?


I suspect that the weak marketing person who wrote this copy thought it “looked nicer” to put features into a long sentence. Let’s look at that sentence, from a copy-writing perspective. It has eight separate phrases. EIGHT. The average sentence has 2-4. Concise sentences have 1-2. Waffle has 5 or more. This is a sales page; every sentence should be no more than 3 phrases. EIGHT! NO-ONE is going to pull useful information from that sentence.

Onto another problem with this page, for the customer who comes here: No screenshots. Anywhere.

OK. Take a deep breath. This is a company that, so far:
– wants to deceive us into locking-in to their product
– patronises us intensely
– works hard to hide features (check that “unreadable” infographic)

…but let’s put all that to one side, and drill down into the links from the Product page.

Features (1 of 8): “You can look, but don’t touch AND DON’T LOOK CLOSELY!”


Finally, if you follow one of the links from this page, you get to a page that contains some actual, concrete, info about the product. There’s even some screenshots!

Oh. BUT. You are “not allowed” to actually see the screenshots. They’ve been deliberately blurred-out a low-resolution, so that text is literally unreadable and there is NO WAY to judge the product. (NB: this is *after* you’ve clicked on the almost-full-size thumbnails in the page). They are then further blurred (to no purpose except to fit the Web Designer’s fetish for popup images) and embedded in the page.

Overall impression: this company knows it’s own product is not fit for purpose, and will do anything to stop the customer from finding that out until AFTER they’ve paid their money. Whatever you do DO NOT BUY VersionOne’s project-management software.

Final thoughts: First one is free

A decent usability person – or a really good web designer – would make huge sweeping changes to that site.

A flippant starter, something I’d personally try immediately (today): move the “see it; drive it; try it” buttons that hide in top-right of the site to CENTER STAGE, both on the Product page and the Google Landing page.

AND … I’d add a fourth button: “Buy it”.

What? There’s no “buy” link on this site? Yep. I think that eloquently sums up what a poor job this site does of MAKING MONEY FOR THE COMPANY.

(NB: and I *absolutely* would instigate A/B tests to prove – day by day, hour by hour – that my changes were having a noticeable effect on increasing sales to the site. If you don’t do that, then you’re just pissing into the wind. You have no idea, afterwards, whether your changes “worked”. See Sergio Zyman‘s book for more…)

Where do these terrible sites come from?

I believe that these often-amateurish websites come from one of two sources (possibly both):

1. Expensive “Web Design” agency that only cared about making it “beautiful” without understanding a single thing about the reality of sales. In the example I run through below, dead giveaways include: Popup images that are only 15% larger than the thumbnails that trigger them; grey-on-white text; very small font-sizes. All those are characteristic of visual designers who know nothing about product sales.

2. A marketing team that’s worked for big corporates (multinational, public companies) and thinks that the most important thing in their job is to “clone” the website of “a real company – you know, like Microsoft”, and pretend to “be like the big boys”. They have no idea why those websites look the way they do, and don’t bother to ask themselves; they just blindly clone it. In the example below, dead giveaways include: 12 pages to describe a simple product where 3 would have been more than sufficient; hiding information at all costs; never committing to a list of features; using “freeform text” instead of simple “bullet points” to describe the product.

agile dev-process MMOG development programming startup advice web 2.0

How to FAIL, from the world of Open Source: Eclipse

The problem

It’s a great piece of openness to put your bug lists in the public domain. It makes it easier for your customers and partners to make decisions that save you time because they can see what’s coming and when (and save you money in reduced support requests). It saves you money in that you get free QA / testing from your users.

The downside is that it exposes to the world the places where you are especially incompetent, lazy, or just plain self-centred.

This is a recurring theme I’ve seen with corporates looking at both Open Source and also Web 2.0:

We say we’re the best, but secretly I believe we’re the worst; if we expose ourselves to the public, people will ridicule our mediocrity, and refuse to do business with us.

Also … I will probably get fired because my colleagues and my boss will finally realise what a clusterfuck I preside over on a daily basis

Eclipse, and a tale of two bugs

I was going to log two high-impact bugs that Eclipse has had for several years. Then I did a search on that area of Eclipse, and realised that the current Eclipse maintainers don’t give a **** about this whole section of the IDE – some of the core bugs we see every day were logged in 2001, and are still open:

What you find when you do some basic research

If you go looking through the bug history for some of the more “obvious” bugs there, you often find little gems of passive-aggressiveness from maintainers. That’s an exceptionally effective way of making sure people stop helping and supporting any Open-Source project…

You’ll also find endless re-logging of the same old bugs from 10 years ago, revolving around the basic problem that Eclipse lets you set everything you could possibly imagine … EXCEPT the colours that it prints text in.

(all IDEs let you set the colours; most dont give you enough control over the other parts; Eclipse fails on the basic challenge, and succeeds on the advanced challenge)

This wouldn’t be so bad, except that its default is very bright with low-contrast – i.e. very hard to read on laptops when outside, and bad to read for long periods of time. As of about 5 years ago, you are finally “allowed” to set the colours yourself – except that the app breaks if you do, because they “didn’t bother” to allow you to change the colours on 20% or so of things.

Final thoughts

The next time someone – especially at a corporate – resists openness and transparency … in any form … ask yourself this:

What have they got to hide?

Often, once you ask yourself that question of the right person at the right time, it very quickly becomes obvious what they’re hiding (if not why). A little more digging, and you can pry open the can of worms, and see what trouble they’ve been up to…

(Incidentally (and unsurprisingly), in the face of the point-blank refusal of Eclipse developers to make basic usability concessions across the board, I didn’t bother logging either of the two bugs I’d found)

agile community conferences entrepreneurship games industry startup advice web 2.0

Free iPhone developer meetups

I just received an “invite” to a pay-for event in London about “smartphone development”: an evening in a bar with a couple of speakers and some networking.

So … you can go and listen to an iPhone developer, an ex EA person, and an ex Motorola person, and pay for the priviledge, organized by non-developers. The cost is 50% more than you pay to go to world-famous VC/angel/investor networking events such as First Tuesday.

Or … you could go to one of the many near-identical networking + speaker events that are free, and run by real developers. Here are four examples which show that Upcoming, – even Facebook and LinkedIn – are your friends here, with loads of stuff going on.

The issue of “how” you organize these things and “what” you provide has been on my mind a lot recently, as we’ve just started a fortnightly one in Brighton (for anyone and everyone interested in commissioning, designing, developing, and launching iPhone apps). I’ve been trying out all the above sites for arranging this (I can write up some notes about the pros/cons of the different sites if anyone is interested). If you can’t find something in your local area … why not start one of your own, all it takes is making a page on, and emailing the local game / mobile / iphone / OS X developer communities … takes about 30 minutes, max?

Personally, I find the grassroots events organized by people actually making this stuff on a daily basis the far more compelling option. I also find that “special name speaker” events tend to focus on the audience being expected to shut up and listen, rather than share and learn collectively – which isn’t much use to me these days. Unconferences for the win!

Of course, sooner or later, if your event gets popular, you’ll have to start charging because the only venues big enough require large payments, and the organization effort becomes too much to do in your free time. But for the small events? My advice: if it ain’t free, don’t go.

agile entrepreneurship games industry massively multiplayer

Manifesto for a Game Development Studio (or any creative tech company)

Here are the founding principles of my next startup. It’s incomplete and imperfect, but for where I want to go … it’s a start. Incidentally, if you share them, and want to work with me, you should get in touch (adam.m.s.martin at I’m sure we can find a way to work together.

EDIT: if you’re interested in these ideas, have ideas of your own you want to discuss, or are just looking for other like-minded people … I’ve set up a Google Group for this at:

30 hour working week

  1. 4 days a week, 7.5 hours a day
  2. Salaries are 20% below the going rates; we aim to employ 20% more staff than usual for a given project size; cost is the same, output is the same (modulo an output-reduction/cost-increase due to increased overheads/inefficiencies for larger team size)
  3. everyone takes the same day off. I’m thinking Friday. Friday sound good? Let’s make it Friday. You know that if you’re in the office, so is everyone else (modulo normal holidays, off-sites, illness, etc).
  4. if we ever have to “crunch” and work unpaid overtime, I’m afraid we’ll all have to start coming in 5 days a week. I know, it’s tough.

Self ownership

  1. you own your work: no-one will chase you; informing people of your status, and of delays, is *your* job
  2. you own your project: everything works on Scrum (where the “team” owns the entire process – no producers, no project managers); NB: if you claim to “know Scrum” or be a Scrum Master, or “have used Scrum” and you don’t understand/believe this team ownership thing, here’s a big fat hint: YOU MISSED THE POINT
  3. you own the company: everyone has vested equity (not options) in the company

Mentors not managers

  1. increased organizational power is based on your ability to bring others up to your level. It’s based on your contributions to the other individuals. It’s not based on your organizational prowess
  2. if you cannot mentor, cannot explain complex/new things simply and clearly … you will not advance in the management chain (you should become a Domain Expert instead!)

Your value is what you are paid

  1. This is an implicit assumption in all salary negotiations and performance reviews.
  2. It will also be required to be *stated* explicitly in all negotations and reviews
  3. If your manager believes you’ve got better, they have to increase your pay
  4. If they do not increase your pay, they’re not allowed to give you a positive performance review
  5. There is no point in your career where “Becoming a Manager” is a requirement to get your salary any higher; the only benchmark is “can you further increase your usefulness to the company?”

You have a duty to become the best you can be

  1. Playing games, during company time, is an expected part of most jobs, since we are a “game development company” and you *need* to know what our competitors are doing
  2. Learning new skills, during company time, is an expected part of most jobs, since we’ll always be looking to make use of any “better” new technologies and tools that become available
  3. Not going on paid training courses, not increasing your understanding of our industry, allowing your personal skill progression to plateau … makes you sink behind what your peers in other companies are doing, people who would like your job. Get too far behind and we’ll give it to them. You owe it to yourself, as well as all the rest of us, to make sure YOU, as an individual, are constantly getting better, and learning new things
  4. The structure of the company is explicitly designed to support as many people as possible to become the best they can be. If in doubt, or in difficult situations where no alternative is “easy”, we will err on the side of helping people to improve themselves.

100% Organization-level transparency

  1. knowing what is happening in the organization is a right, not a priviledge
  2. knowing the reasoning behind organization decisions is a right, not a priviledge … from the reasons behind a marketing campaign being run the way it is, to the reasons for the product strategy, to the reasons that one particular tech is being used rather than another
  3. being informed of the progress of ongoing processes / issues is an expectation, not a priviledge … that means that people working on things are expected to proatively inform the rest of the company what they’re up to
  4. transparency overrides privacy (unless forced otherwise by explicit legal requirements)
  5. e.g. the salary someone earns is a personal and private matter – but the salary the company pays to each of its staff is not, and every member of the company has full free right to see that info. The company knows additional things – e.g. thanks to tax law, companies may know of other income their staff are receiving – but those are not part of the company, hence they are not part of the transparency

The buck stops with the directors

  1. any issue that necessarily has to be handled by an individual, that can’t be handled by the “team ownerships” etc, or e.g. is “sensitive” or a private personnel issue, WILL be handled by a named director instead
  2. no manager can accrete decision-making power, unless they are a company director
  3. e.g. if too much power is taken away from teams by directors, by accident or device, the directors will become overworked and will have obvious incentive to push decision power back to the teams

Google 20% time

  1. Problem: it’s either half a day, 12.5% time, or 1 day, 25% time. I’m not happy with either – one whole day makes things much easier mentally for the person to switch, but I’m afraid that converting it to 25% time and having people available only 3 days in every 7 would be too destructive?
  2. As per Google, this is not a right, it’s a priviledge
  3. all 15% time projects require sign-off by the person’s direct manager (with appeal to a director)
  4. all 15% time projects require monthly status presentations to show what’s been achieved, and the manager has to approve or deny continued work on the project

Team budgets – food; drink

  1. every project team has a weekly budget for food, and one for drink, and is expected to on average have one team lunch a week, and one team evening social (with free alcohol) per week

Healthy food; healthy environments

  1. the office will not have Cola vending machines, or ChocolateBar vending machines. *If* it has any vending machines, they’ll be majority subsidised – free, or practically free
  2. the office will have a surfeit of fresh fruit, renewed every day, starting at or before anyone gets into the office
  3. any meeting called before 11am will have some free small fresh food with substantial sugar content (for anyone who missed breakfast. Until they recharge their blood sugar, they’re probably cranky and irritable – and irrational – or simply silent and unthinking, like a robot, and make everyone else suffer because of it)
  4. choosing to hold meetings physically outside the office, e.g. in local cafes, and having the company pay for coffees and snacks, is a right, not a priviledge, for all employees

Remote working, and Online Working

  1. at any given time, we aim to have a substantial minority of staff working remotely / telecommuting, e.g. around 20%
  2. remote workers can expect slightly lower salaries than their full-time equivalents; the company gets more value out of people who are co-located – but it makes all of us work better to have a mix of co-local and remote colleagues, so we welcome the presence of remote workers
  3. all employees are required to be online and available *and reactive* on IM during all working hours
  4. all development systems and tools will support remote working by default (e.g. remote compilation, remote builds, remote deployment, remote access for all internal systems). This is one of the ways that having remote staff makes our overall operations better: better tested, more robust, more adaptable
  5. all employees will have their own password-protected SSH keys stored on a free USB key; all company systems will work on SSH key-based auth; all workstations will be configured to do single-sign-on using the individual’s SSH key – no passwords required

Guards against the unscrupulous

  1. all ownership is only part-vested, tied to time served AND ALSO personal performance targets. This will take substantial time to invent/negotiate on a per-person basis (I know, I’ve tried. Sometimes, I’ve given up on it, because it was so much effort. But … in the short and long term, its worth it)
  2. managers have more time to look for problematic individuals, as they’re freed of some of their normal duties in other companies
  3. teams, being self-owning, have the power and the incentive to reject any failing members. Over time, failing individuals will either change, find teams that do welcome them, or find themselves conspicuously under-employed, making them an easy target for management attention (this does not imply “firing”, it’s up to the management what action they take, but they clearly now have staff they’re paying for and getting nothing from)
  4. directors have a lot of burdens of responsibility under this system; they also have a lot more visibility into the company’s status than in a standard company, so more chance to fulfil their responsibilities
  5. most of the processes are designed to be self-healing/recovering when encounting unforseen problems: the teams and individuals that do the bulk of the actual *work* are self-owning, the managers whose roles are mostly shepherding are largely disempowered to break anything, any unusual problems fall into the laps of the Directors who already have total legal power to enact whatever is needed anyway, etc.

Next steps

Please help me debug this thing … add your own suggestions, or highlight the flaws in what I’ve written, or point to evidence both for and against the realities of what might work … etc, etc, etc.

agile community computer games entrepreneurship games industry massively multiplayer

How can we make a Europe-wide MMO Publisher?

(4 posts in one day? Yeah! Too busy to be regular right now. GDC is on the way)

At the end of my commentary on the formation of NC West, I added almost as an afterthought a little comment about Europe and the MMO industry:

there’s a gaping hole in the MMO sphere. For someone bold enough to step into that hole, you could “own” Europe’s online gaming industry for the next decade.

Since I wrote that, surprisingly many people have commented on it both by email and in person, either along the lines of “look who else missed the opportunity” (Jagex, Ankama, Bigpoint, Gameforge), or along the lines of “yeah!” (count me in) … or both.

So, I wonder: what *would* it take, right now? If you have ideas, post them here. I’ll be at GDC in 3 weeks time, and I’d be more than happy to pitch this as a credible plan, if you come up with a comprhensive-enough plan. It’s a lot more expensive than any of my own humble plans, but in many ways I find it a lot easier to justify, financially. And I’m not even trying (it’s just a game for me right now, idly imagining what I’d do, if I were Jagex, or Ankama, or Gameforge, etc).

Wishlist time. Over to you, Dear Readers…

agile games design iphone programming recruiting

iPhone Creators: Brighton pub meet March 9th

If you have any interest in iPhone development (you have ideas for apps, or you want to start coding for your iphone, or just want to meet other like-minded folks over beers), then come along.

Bring friends. Bring iPhones (I’ll bring my laptop so you can download and try my current work in progress)

If you’ve got anything you’ve made yourself, definitely bring it along!

We had a quiet first meetup last night, I’ll be adding screenshots / app descriptions for the two apps shown on the night to this post later.


Snooker Scorer

snookerscorer1 This is a simple app that keeps score of a snooker match. You can use it in a club, watching a match live or even following on tv.

Just tap the ball that has been potted. Hit the ‘swap’ icon to swap players. If a foul happens, hold the ‘foul’ icon and tap the ball fouled. Free balls can be added as well through the popup actions icon.

Future additions will make the information line adapt to show the most relevant info such as current or maximum break, difference and points remaing, balls potted in current break, match history, undo mistakes, and whatever else I can think of.

agile community entrepreneurship web 2.0

The Rules: Open Source Startup Funding

Mark Cuban’s blog is an odd one; I really can’t remember why I started reading it (presumably linked by a VC blogger would be my guess), and yet even though I read very few blogs I’ve stuck with his. It’s not like the standard SiValley other investor/commentator blogs. It’s a lot more based in the real world, and a lot closer to my experiences of running the business side of a business as opposed to the “building to flip” side of running a startup without ever being profitable just to sell it to someone else.

Anyway, advert over. He’s posted an interesting challenge: want money for a startup? Right. You have to publish the entire business plan, and let everyone else copy it. If – as many people are fond of saying – it’s implementation that matters, not the idea, then this shouldn’t be a problem for you. But it may bring wider-world benefits to everyone else, intangible virtuous-circle stuff.

I will invest money in businesses presented here on this blog. No minimum, no maximum, but a very specific set of rules. Here they are:

1. It can be an existing business or a start up.
2. It can not be a business that generates any revenue from advertising. Why ? Because I want this to be a business where you sell something and get paid for it. Thats the only way to get and stay profitable in such a short period of time.
3. It MUST BE CASH FLOW BREAK EVEN within 60 days
4. It must be profitable within 90 days.
5. Funding will be on a monthly basis. If you dont make your numbers, the funding stops
6. You must demonstrate as part of your plan that you sell your product or service for more than what it costs you to produce, fully encumbered
7. Everyone must work. The organization is completely flat. There are no employees reporting to managers. There is the founder/owners and everyone else
8. You must post your business plan here, or you can post it on , or google docs, all completely public for anyone to see and/or download
9. I make no promises that if your business is profitable, that I will invest more money. Once you get the initial funding you are on your own
10. I will make no promises that I will be available to offer help. If I want to , I will. If not, I wont.
11. If you do get money, it goes into a bank that I specify, and I have the ability to watch the funds flow and the opportunity to require that I cosign any outflows.
12. In your business plan , make sure to specify how much equity I will receive or how I will get a return on my money.
13. No mult-level marketing programs (added 2/10/09 1pm)

PS: I love Mark’s attitude that comes across in his blog. E.g. in one of the first comments to this blog post:

Would you be open to reviewing pitches on your blog and then details privately?

From MC> No. This is an open source opportunity. Not a pitch Mark opportunity

agile dev-process programming web 2.0

PHP: Looking for some Best Practices

PHP is weak, crappy, and encourages people to write terrible code. But … if you know what you’re doing, all of those might actually be really really good things.

(by the way, if you haven’t already, you should read Eric Ries thoughts on PHP…)

“Best Practices” are one of the best guides you can get for sailing between the Scylla and Charybdis of “crap code” and “over-engineering”.

So I’d like some, please.


Anyone with zero computer science education can write crap code; that’s easy. At the other end of the spectrum we have the people who write Perfect code.

Anyone who writes perfect code is either:

  1. a liar
  2. too rich to work for money
  3. works in an industry that is immune to marketing

…because marketing is always a cheaper and more effective way of making more money, compared to writing “perfect” code.

(disclaimer: in the past, I’ve been the first, and lusted after the third, but never quite managed the second)

The skill that marks out the difference between a competent programmer and a good (or great) one is knowing which of the language’s strengths to play up, and which to play down. Sometimes, the fact that a language allows extremely sloppy code is a very good thing. e.g. most scripting languages – especially any that run on an “intelligent” runtime like the truly Awesome JavaVM – where being grossly inefficient is not only “OK” but in fact “doesn’t happen”, because once it notices what stupid thing you did, the runtime silently recompiles everything into decent C code while you’re not looking.

So … how the heck do you win?

You look for Best Practices, language-specific (and domain-specific, but that’s obviously of more niche value).

I recently did two moderate sized PHP projects. I figured: OK, so PHP is very easy to hack code together knowing very little about the platform (and I’d been using my Perl experience most of the time when writing PHP) – but Perl showed us that Best Practices are damn useful and not too hard to stick to. There must be lots that the PHP community has worked out by now!

(as Quake3 would say, in a bass rumbling voice:) Denied!

Um, no. Apparently not. Google – with *considerable massaging* – threw out a few dozen attempts from different people.

There was some interesting stuff in there. I found some obscure bits of standard and near-standard extensions I hadn’t noticed previously when reading the manuals.

But, to be honest, nearly all of it was a waste of time – it simply wasn’t PHP specific. Telling people that they should “document function headers” is meaningless as a “PHP Best Practice”. It’s not a PHP Best Practice, it’s a general programming practice. You can find it in *any* textbook (and if you don’t know stuff like that, I suggest you go read a few key books like Code Complete, for starters).

There’s also – and this quite upset me – a lot of BAD practice out there being passed on from PHP programmer to PHP programmer and hailed as if it were “a good thing”, when often it’s about as wise and valuable as staring down the barrel of a loaded gun so you can see better while you clean the inside.

What is PHP good for? Why?

I have recently realised that the majority of PHP programmers cannot answer these questions, and that many of the rest aren’t great at answering them either. If you can’t answer them, you can probably never be a great PHP programmer, and it’s debatable exactly how “good” you are. (/me ducks and runs for cover)

I’ve not done enough PHP to know what it does from the inside.

But I’ve done tonnes of code in “languages that are not PHP”, and I have a really really good idea what it does from the outside. And most of the Best Practices I saw for PHP were stolen from other languages (especially C derivatives) and are totally inappropriate for PHP. Because PHP is not C, and PHP programmers will never be decent C programmers, no matter how big their inferiority complex, and no matter how hard they slave to try and write “high quality code”.

Some things PHP is good at: (in no particular order!)

  1. It’s a Scripting Language (like JavaScript, and ActionScript, and Perl. But not like C, and not like C++, and not like Java)
    • It’s intended to be trivial to read and write code; the core language is “easy for a non-programmer to grasp”
    • There’s no feature in the language that requires thinking to understand what’s going on, by design (unfortunately, some of the libraries broke this. c.f. the great Register Globals disaster too)
    • idiots can code effectively…
    • …which means that highly intelligent individuals who were never trained as programmers can ALSO code effectively, with minimal pain and suffering
    • …and that changing (modifying, fixing, extending) other people’s PHP code is trivially easy
    • There’s no compiler. No cached builds. What you see is what you executed, literally.
  2. It’s very easy to grasp two of the three most important structures of a web application (the third one is “data flow” – PHP sucks at that one). The two it does great are “program logic” and “program inputs + outputs”; together these sum to “execution structure”
    • One page == one source file : you read an output (FORM or A link) to an HREF? Or a page is crashing in the browser? You know exactly which file to find it in
    • One source file == one page : all the logic (PHP tags) and the input/output parts of the user-interface (HTML tags) are in one file. So you can’t make assumptions and the resulting mistakes
  3. It’s a context-free language. This is a by-product of being so tightly integrated with HTTP/HTML. It is one of the things that “real” programmers sneer at PHP for – how can you have a context-free language that isn’t Functional and expect it to be any good? That’s some kind of mutant offspring of Fn and Imp that ought to be strangled at birth. Or … maybe … just maybe … it’s one of PHP’s greatest strengths (although admittedly it is a mutant offspring too)
    • When a single source file is executing *there cannot be any other context* (except for the Session, sadly – but this is a strange piece of context-that-is-not-context because of all the rules about what can and cannot be in a session)
    • Oh, OK: there cannot be any context from other threads, other users, other simultaneously executing code. This is one of the hardest, nastiest parts of all systems languages, the multi-threading stuff. And PHP completely wipes it out as a problem. Nice.
    • All source files – hence all user-interaction points – are (semi-)atomic by definition: either they execute, or they don’t (by default, if they start, they dont stop, not even if a crash-level event happens; more on that later)
  4. Code is mingled with presentation, but is “together but apart” because it’s guarded (in the computer science meaning of that word, sort-of) by enclosing magic PHP tags
    • You can copy/paste move around code without the risk of it becoming part of the presentation code (this problem happens A LOT (and causes some awful security holes and application crashes) in some languages, especially in templating languages, even though it seems like such a simple thing. I kid you not.)
    • Any decent IDE (/wave at Eclipse (download PDT to add PHP to it)) can do a lot better at second-guessing what the programmer wants to type next, thanks to the explicit context of being either “in code” or “in presentation”. Saves a lot of time, in very small pieces many times a day.
  5. It’s a mainstream scripting language: very very fast to write code, code is very very fast to read + understand (it CANNOT DO complex things like STL or Operator Overloading), and you can “make it up as you go along” when writing a program – it doesn’t expect you to plan ANYTHING in advance
    • No declarations : you don’t have to plan your variables in advance
    • No declarations = faster “flow of mental programming” : you can aribtrarily change your mind “mid sentence” when writing code, and not have to move backwards in the source file to fix a declaration as a result
    • No memory management : you don’t have to plan the LIFECYCLES of your variables in advance
  6. Writing basic imperative code. Fast. (Imperative == “not Functional”; if you don’t know what that means, look it up – Fn programming is awesome)
  7. Templates for pages.
    • If you’re going to use a template method (or, god forbid, “library”) in PHP, make sure that its source code looks *exactly like PHP*. Because PHP is an excellent templating language.
    • This begs the question of “why aren’t you just using PHP in the first place, fool?”. The answer to which is usually “I didn’t read Adam’s Best Practices on this website and wrote long waffling PHP source that no-one could understand”, or “I have some truly stupid accomplices who will overwrite the PHP tags whenever they see them, just for fun” (anyone using DreamWeaver has almost certainly done this at some point, without even realising it; in that case, it’s not the human’s fault, it’s the fault of their editing software – DW – but the PHP programmer can’t really tell the difference, it’s the same net effect)

Some things PHP is bad at: (in no particular order!)

  1. NOTE: just because PHP is “bad” at something does not imply that this is a bad thing about PHP!
  2. OOP. PHP is poor at OOP. It’s not as bad as Objective C (which is terrible) nor Perl (which is horrifically awful at OOP), but it’s not part of the core language, and it shows.
    • Actually, I don’t even know what to say here. Go on a long rant about how it should look like C++? Hmm. Not really helpful. I’ll just leave it at that. If you *really* need to ask why PHP’s OOP is bad, it’s going to take more than a couple of bullet points to explain it to you.
  3. It’s an “old fashioned” scripting language; it lacks some so-called modern features (many of them are older than the microchip but took a few decades to make it into mainstream programming)
    • Closures? Where are my closures? : without this, it’s much harder to write self-adapting code, and much harder to write code “for other programmers to extend and alter without needing to change my source code”
    • No OOP scripting : without this, OOP is a pain in the ass, taking a lot more typing, and standing out like a sore thumb inside any PHP file
    • No modern Array derefence syntax : (you have to do: “${arr[‘var’]}” instead of: “$arr.var”) this makes getting data out of arrays so hard that people go out of their way not to use arrays in PHP.
  4. Data flow (the third prong of three mentioned in the Good bits section)
    • SQL in PHP is not fun : it’s all manual SQL statements, with practically zero language-level support (check out Perl::DBI for an example of how funktastic language support for SQL can get; I didn’t say “good”, I said “funktastic”. There’s a difference)
  5. Distribution
    • There isn’t any. PEAR doesn’t count – and if it did, well … PEAR has one of the most appalling distribution systems I’ve seen in about 10 years. The fact that I had to hack PEAR’s installer – in 2008 – just to “not crash” let alone to get it to “start installing” says it all, really.
    • No package management. No bundling. No metadata. No repository (PEAR or CPAN? take your pick. I find both fine as manual systems, and frequent failures as automated systems).
    • (if you still don’t believe me, find yourself a Debian sysadmin and ask them to show you Aptitude, a worn-out decade-old text-based front-end to apt. And marvel at how fantastic it is despite all that!)
  6. Register Globals fiasco : the maintainers killed some core features of the language in an attempt to fix a security hole, instead of just fixing the security hole
    • Sadly, the core libraries now force you to use Arrays for evertying, because the language maintainers panicked over Register Globals and destroyed the whole input-sampling system.
    • …which is bad because of the lack of Array-de-ref syntax in the language (see above)

A quick retrospective

If you’re a PHP programmer, I hope you’ve already noticed the implications of some of the good/bad points I hilighted.

There are things that a lot of the PHP community loves with a lack of reasoning that sometimes borders on obsession/fetishism, but which – from the above analysis – are inappropriate for PHP. I’ve tried some of these, and confirmed: whoever thought this was a good idea was either smoking crack or didn’t understand how to build web applications.

Some quick examples:

  • Page Caching. You gotta be kidding me. There’s are plenty of reasons that all other languages push this OUT of the language, and OUT of the application, and most of them apply equally to PHP. Use Memcached instead, and learn to use it properly – that is, externally, not internally.
  • Separating Code from Data. As a gross generalization, if you do this, you should stop writing PHP, because you just threw away most of the benefits of PHP, and you’d be better off writing J2EE from this point on – you’d get the benefits of J2EE and of the Java language AND of the Java standard libs (which kick the living daylights out of PHP’s weak set of “Extensions”) – and you’d hardly lose anything in the transfer.
  • M/V/C architectures. If you do it the way we do it in other languages, then it’s equally stupid as the above point. It *can* be done, conceptually, in ways that fit with PHP – but the majority of PHP systems I’ve poked inside didn’t get that clever, they just tried to do it the traditional ways.

By The Way: I’m probably wrong on some of this. I haven’t spent much time thinking about it. Unfortunately, I’m not sure at this point which points are where I’m Totally Right, Dude, and which ones are where I’m Smoking Something Funky.


Too many words! Argh

I keep being told off (nicely) for writing blog posts that are too long.

In petty revenge, after making you read through the rant-tastic introductory bits (I have my Asbestos suit at the ready…), I’m splitting the rest into a separate post. I almost feel bad about doing this. Almost.

So, on to … PART 2: Best Practice for PHP Programming!

agile dev-process games industry

What are the core competencies that every producer must possess?

Lots of ideas and detailed explanation from games industry Producers and production staff on the IGDA Production mailing list here.

Unfortunately, I’m afraid that the people who run the Production SIG don’t believe in allowing you – the public – to read their conversations. So all I can do is tell you that there’s good stuff that would probably help with improving the quality of the process in the industry – and hence improve the quality of life of everyone involved – and give you a link to go and apply to be allowed access to this secret world.

Sorry. Good luck with justifying your existence enough to be allowed in; I hear they are pretty generous with it (hey – they let *me* in :)), so you should be fine, I think.

(“IGDA: hiding information that would help people break-into the games industry, or improve their own level of professionalism, since 2004

PS: because it’s password-protected, and uses random passwords, I can’t even get hold of the direct link to the emails in the archive – I have to wait for their mailman server to give me my password. That can take several hours (I know there’s nothing they can do to improve it: I run one of the other lists on the same server, and have the same problem :( ), so I’ll edit-in the direct link if/when my password arrives)

agile dev-process games industry

Problems to Avoid as a Scrum Project Customer

(I’m quoting a very handy short extract from Clinton Keith’s December 2007 Gamasutra article, so that I can find it again easily later. Clinton is/was the CTO of High Moon Studios, and is probably the most well-known proponent of Scrum in the games industry. Rather than wade through the whole article when I want to pass on some of his advice, I wanted to be able to copy/paste the relevant sub-bits)

agile dev-process games industry

Problems to Avoid When Introducing Scrum to Customers

(I’m quoting a very handy short extract from Clinton Keith’s December 2007 Gamasutra article, so that I can find it again easily later. Clinton is/was the CTO of High Moon Studios, and is probably the most well-known proponent of Scrum in the games industry. Rather than wade through the whole article when I want to pass on some of his advice, I wanted to be able to copy/paste the relevant sub-bits)

agile devdiary programming

Writing games in Korean – part 3

Computer grammars, Unicode in Eclipse, and problems with Java’s XML parsers…

agile computer games dev-process games industry

Fighting Consulting Firms

a.k.a. how some Publishers view independent Developers

This is a quote found buried in the middle of the otherwise completely unrelated, but sometimes highly amusing, “rant to end all rants” about the rise and fall of the talent and skill of the people within the Ruby on Rails development community:

I have a few pieces of advice for people about to hire any company like ThoughtWorks. There’s just a few simple strategies you can follow to make sure you get the most out of them and get your money’s worth:

1. Make sure you have the right to see every resume and interview each consultant they place. Treat them like new hires and don’t let anyone who’s not worth the rate you’re paying on the team.
2. Demand a variable rate based on the position of the person and their experience.
3. Demand that no employees can leave the project to work on another project. These placements have to be for the life of the project or until the employee quits.
4. Require that you have the right to have someone replaced if they are not immediately capable. Part of what you’re paying is that a ThoughtWorker should be able to drop in commando style and just start working. The reality is they are usually totally lost anyway.
5. Seriously consider recruiting one full time employee as a team lead, another as a project manager, and then staff the rest of your team with independent consultants. You’ll find that you get more control and better quality at a lower price.

Having employed one extremely famous web-design consultancy, run by some of the most famous world experts in using XHTML/CSS (and doing so attractively), and had very similar discoveries/realizations about their dodgy business practices when we were charged 5-figure sums for 3 webpages that were thrown together in around half an hour … in 2005 … I found the list above quite a good starting point for anyone considering paying an external team of experts :).

At some point, I’d like to followup with my own lessons learnt from what to do and what not to do on the publisher side of the game-publisher/game-developer relationship.