I remember they pretty much set the pace for my whole seven years there more or less. They were quite established in what they thought was good design and good practice. The engineers that is, not the management team at all, the engineers… So I did my design one way and I named my stuff one way and they were like “Well, it shouldn’t be named like that.” We’d just end up having a huge argument about what things were called; and then we’d have these arguments about design and everything else…
They were fond of implementation inheritance, which is a massive no no I think. I’m sure most people would agree, but over time we explained why and things changed. As new people came in they were more interested in doing things properly and fast, and implementation inheritance is quite a step away from going fast and having good quality. Implementation inheritance is essentially a way to introduce lots of complexity and spaghettiness into your code. I mean I’m sure it can be done properly, but it doesn’t need to be done so don’t do it.
The power balance in the company was very much biased towards engineers. The marketing and sales team felt somewhat disenfranchised. The senior engineers would do favours for the sales guys; it was like a buddy, rub my back, rub your back system. This is fine for a small company but I was number 26 in the door, this company was expanding rapidly so it broke down very quickly. Doing the product ownership thing was an excellent way to start evolving.
There was massive mistrust from the marketing side and the engineering side - they would both bitch about each other and all this. So, having them actively involved in the projects was really giving them a day-to-day stake in it. It was a good move, I would say.
At one point it all went a bit bad actually. There were three at the time, two from marketing and one from the science team. They got very, very frustrated with various things going on with the projects. They felt they weren’t being listened too, they didn’t like the fact that stories were slipping from the iterations. The solutions that they put forward were in my opinion awful: things like if things were slipping out of the iteration they should work all night to finish it. They said to me that the reason things were slipping was because the estimates were just totally out.
So what we did there was we used a slight variation on critical chain project management. We tried to do it on a per task basis, just inside iteration. The idea is that there’s a calculated buffer there for the iteration. It also meant that we aggressively slashed all the estimates. This was nonsensical as it meant that if something went well the team weren’t able to take the benefit of that. For example train timetables: the way they work is that a train can’t get any benefit from running ahead, if it runs ahead when it reaches the next station it has to await for its allotted time before it can leave… Instead of having a system where things can go well and badly and they can cancel out sometimes, what you get is basically that it adds up all bad because at any over run is cancelled out. It’s the same in projects and in the critical chain.
People felt quite disenfranchised. Around about that time the Marketing Director and Technical Director decided that they had had enough of this bickering, if we couldn’t sort it out amongst ourselves, so they imposed themselves on it which was a really bad move. They hadn’t got enough time. So things didn’t really improve.
The company never got the customer thing right. I later came to realise that it was down to the fact that inside the business they do not actually know their customers well enough. They were doing things that were logical on one hand, but if looked at from the point of view of not understanding the customer, that were fatal for any company. They were basically putting other concerns in front of that.
There were quality issues. And at all sorts of levels. It showed up to the user in terms of bad UI design, because there wasn’t enough time left. That says it all - there wasn’t enough time left to improve the UI. The messy codes often meant it ran slower. The engineers started to find it more and more exasperating to work on; both in terms of having to use it, and it was a nightmare, but also because the spaghetti code was trying to get them.
It was a classic situation: “Can you make this change?” “Yes.” You trace the code, blah, blah, blah, change it, you check it, and now that’s working get someone else to check it, so that’s working. You send it off to the tester, the tester’s experienced, knows the software, knows to check all sorts of unrelated things, find something either utterly unrelated that now doesn’t work or finds out that in certain situations it was now showing old behaviour. This was because maybe there was two things going on inside the code, with multiple paths to the same thing. So an engineer would come along and change what they thought was the path, completely missing the other path. There was also this weird reuse of code, where if you altered it for your purpose, not realising it had a secret second identity, you would end up buggering up this other menu option with some other thing.
delicious
digg