The other aspect of this that I see, even in seasoned engineers, is the 'presumption of simplicity'. Some things look really simple, but inside they are actually quite complicated. A smart phone is just a screen, a computer, a battery and a radio right? Too many times people see something, think "that doesn't look too hard I bet I could do that in a weekend"[1] but don't actually follow through on that thought and spend a weekend building what ever it was that was so easy. Sometimes the more experience you have the more dangerous this is. I can recall times in my own life we're I've grossly underestimated the difficulty of stuff, its lead me to be a lot more conscious about things I know about and things I think I know something about, especially when predicting schedules and work effort.
[1] A very common theme on acquihire stories here.
For example, a singleton is easy to learn and easy to use, but since every function using it adds a hidden dependency it quickly grows in complexity to the point its impossible to reason about it without forgetting something.
On the other hand, a Promise is simple as it depends on nothing but a producer and a consumer, no matter how much you compose them. Yet I've seen many experienced developers struggle to learn how to use them as they're not easy to understand at first.
This is somewhat related to meta ignorance. From my own experience I've seen a tendency in novice programmers to stick with things which are both easy to learn and use. Their projects go well initially but they grow less and less productive over time as complexity creeps in from the composition of all these easy to use things.
I've always said experience in our industry is knowing what not to use in order to stay productive in the long run.
Here's a link to Rich Hickey explaining it in depth: http://www.infoq.com/presentations/Simple-Made-Easy
Also note that english isn't my first language (I'm french Canadian) and even here in french the distinction is seldom made.
The distinction between two main types of simplicity, those of parsimony and elegance, has been a long-standing philosophical topic [1].
In engineering, the so-called KISS principle (first coined as such in the early 20th century) has always had the implication of minimalism and implementation simplicity, in contrast to mere ease of use.
Fred Brooks wrote a famous paper in 1986 [2] perfectly describing the differences between accidental and essential complexity, and of the semantics of complexity management in software projects.
Hickey has said absolutely nothing spectacular, but his name comes up every time from the typing fingers of the historically illiterate whenever simplicity and ease of use are brought up.
[1] http://plato.stanford.edu/entries/simplicity/
[2] http://www.cs.nott.ac.uk/~cah/G51ISS/Documents/NoSilverBulle...
Rich Hickey gained fame for this because he stated an idea very clearly and compellingly, this is non-trivial and should not be so flippantly dismissed as just recyling old ideas—all your ideas are recycled too.
+100 for this.
I knew about KISS, but almost every time I hear someone mention it they think about ease not simplicity. I will also definitely check out Brooks' paper.
While I understand your position, I believe a lot of this has been lost to the new generations of engineers and what Rich did is remind them of it.
In the parlance of Mr. Rumsfeld, you can learn from the known unknowns, but often you don't even discover the unknown unknowns (the "meta-ignorance") until it's too late.
This, like most engineering tasks, is more straight forward. You have to know what its going to take to build each piece and assemble them into the final product. So if you are making a AAA indie game, it helps if you can talk with the project manager at a company that made AAA games and go through their list of deliverables, and then think about how you're going to deliver the same thing. Sometimes you'll be tempted to say "we won't need to do that" but like Chesterton's fence, you need to understand why they did that so that you can really say you won't need to do that thing.
It is always ok to start with "how hard could it be?" but that starting point requires you educate yourself on exactly how hard it could be. For game development I think pretty much all the questions are knowable (except for consumer reception of course)
"Chesterton's fence is the principle that reforms should not be made until the reasoning behind the existing state of affairs is understood."
I learned something new (and useful) today. Thanks!
Source: https://en.m.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fen...
Yeah, it's descriptive. I think I re-purposed a term from an academic paper that referred to meta-stupidity: stupid people are too stupid to know that they're stupid.
They did an experiment where they got people taking an exam to guess what mark they were going to get. In general, the lower scoring people in the exam over-estimated their mark more than the smart people.
Part of why it's good to be cautious around self-proclaimed experts.
Its very easy to forget all the efforts invested in learning a skill when you've been using that skill for many years. When it becomes second nature, you assume its also that way for others.
I definitely do the "manager doubling" when it comes to estimates. If I think it'll take a month, I estimate 2 months to my boss. If I have to report several levels up, I multiply by 2 for every level.
This tends to affect future work rather than the current sprint.
Hah, I like this. Every level up that sees it is also a potential for more scope creep, as each person will have their own vision of what's being produced.
One of my favorite estimating guidelines from a mentor was that development tasks are either 2, 4, or 8 hours. If it's more than 8 hours it can be broken up into smaller tasks.
1) Daily report in the morning SCRUM style of what was tried, and what's going to be tried next. 2) After a full working week, reassess everything and try and understand where you are going with this.
Rinse and repeat. Basically the estimate is set at 5 full working days whenever you work on an obscure problem. But it's not a hard deadline. It's just a hope that it'll work out by then and a mild mental aid of giving something to work towards.
I ask this sincerely, because I am trying to find a way to approach office politics as just part of my job and play it well. But as a developer, I'm also trying avoid the version of office politics where you just promise impossible things then find scapegoats later.
- I think there will be some challenges in that, can we take some time to think through the implications of ______ (or how we would deal with _____, etc)
- I think it's a great idea, but we're going to need to come up with a creative solution to solve _______
- I think we're probably under-estimating how much work that is. Maybe there's a smaller version we could start with and progress from there.
- We've looked into this before and got stuck at ________, do we think we've got a solution for that?
Once you have committed to doing something, experience usually wins out in doing it better.
"Hofstadter's Law" at work: any unfamiliar task will take longer than planned, no matter how much extra time there is the plan. You can't account for your ignorance with padding, you need some kind of actual knowledge.
The result, then, is that there are only a few ways to actual make an AAA game. One is to hire some quorum of people who've already made one, so that they can bring you up to speed. The other is to do enough proofs of concept that you can see the problems coming.
It looks like Woolfe went from some mobile, educational games to a AAA PC title. That, it seems, was too big a gap to predict and prepare for the hurdles they would face.
Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law.
I've always known this as Cheops's Law: No project is ever completed on time or under budget.
In his biography, Elon Musk acknowledges that his original estimates for SpaceX were completely ridiculous and based on his experience with writing software and ignorance of the realities of building spacecraft.
a. "things that would mean the project failed."
in contrast to:
b. "things that could lead the project to fail."
For "a" one could list. There is no money left. The team desintegrates. Etc...
And finally ask yourself, what could I do now so that, if we arrive to any of the listed sutations the damage is reduced.
Take this comment with a grain of salt. As every other comment on the internet.
After doing all the normal project management estimates, etc, the very first thing he does is sit down everyone who will actually be implementing the project (or a representative sample).
He then asks them a simple question: "Come up with one scenario where this project would fail."
The implication being that this is lateral to the train of thought people use to make initial estimates. Iow, in all possible estimation scenarios, the project is assumed to have been a success! It's not unreasonable to expect that implicit optimism to filter down through sub-estimates.
His point was that giving people permission to imagine scenarios for total and abject failure identified important risks that could be back-fed to improve the initial optimistic estimate.
I pulled in a sample of people from the development team and proposed the following scenario:
It's the Monday morning immediately after our implementation, and you come in to the office to find a bunch of senior managers discussing a big issue with the system.
What went wrong?
That brought up a huge number of potential issues that were sitting in the back of the engineers minds that have never been written on any risk register, etc.
We talked them through, got comfortable that some of them weren't really likely/possible, and then worked on mitigations for the others (mostly via test plans)
In the end, the implementation was a success.
Whenever I'm about to build something big, I first start thinking about things that would be hard to do, or perhaps that I even don't know how to do yet. Then I build prototypes of those to make sure I can to it and do it efficiently.
Once all pieces are ready, it's just a matter of putting them together which is straightforward and you have some chance to actually estimate the time.
Want to do better or find an edge? Figure out a way to be part of a better reference class.
Given a particular problem of a similar sort to something he's worked on, an experienced engineer will be able to list 10 different issues that might crop up.
An inexperienced engineer won't know of those potential problems and will just see the most optimistic path possible.
When you're moving massively outside your familiar zone, many unexpected problems will crop up. Best solution is a phased approach. Pick the bits you judge as most risky (you should hopefully have some idea) and implement prototypes in those areas, in the hope that most of the scaries will crop up. You've then got a better idea as you move on.
I've written this in the context of doing engineering, but it's equally true in all fields - like trying to sell a product into a new an unfamiliar market.