The Speakers have cool little digital versions of themselves on their website
Today Robert Hogg (Managing Director) and Steve Spencer (Development Director) from Black Marble studios gave a special optional lecture on Software Engineering “War Stories”. It was not only great to learn from the mistakes and successes of people with about as much experience as you can get, but it was delivered in a genuinely enjoyable and fun way.
According to their website Black Marble are a “highly skilled software development and IT consultancy house based in the North of England”, from the lecture it seemed that they are specialized in saving “Death March” IT projects, projects that are over-budget, late and not fulfilling customers requirements. It’s scary how many projects face such difficulties, we were told that out of all projects only around 24% are deemed successful, I.e the deliver exactly what they promised within the time promised and at the cost promised. A further 34% encounter problems and end up being either late, over budget or fail to meet all of the requirements. The remaining projects flat out just lose money with no final product of any value to anyone.
“War Stories” are the stories of how the projects that Black Marble came in and saved got into the mess they were in. Some projects go surprisingly far before management realises something is wrong, one example Robert gave was a project that was in its second year, even though it was scheduled to last only a year and was over £7 million over budget, and the way the company was going it was going to take another 5 years to finish off, at even more expense.
It was a long lecture and I couldn’t possibly write in detail about everything I learnt, so here’s a bullet point summary!
- You will work on a “Death March Project” at some point
- Project Management (or lack thereof) is more likely to cause problems than technological factors are
- It is better to stop for a few hours and replan part of the project then work endlessly trying to catch up on time delays
- Sometimes its better to cut features and deliver something in the time frame than not
- Don’t be bullied into making a price/time estimate on the spot by customers, but don’t take more than an hour coming up with one
- Rather than telling a customer their idea is stupid, explain to them how it makes little sense in the context of the application or make it financially unviable for them to include it in the requirements
- Don’t stop learning, computing changes entirely every 10 years. So what you learn now is irrelivent in 10 years time. Take 4 weeks a year to learn the latest stuff in your stack (I.e. Microsoft Technologies, Google Technologies, Apple Technologies, Linux Technologies etc.)
- Don’t write something because you want to. Write for the customer. Why develop a compiler if you’re working on a finance application? (Apparently a surprising amount of software engineers do this)
- The customer is always right. Work to the requirements and you get paid.
- Don’t be over helpful. If the customer wants a system, don’t add extra stuff in because you think it makes it better. This takes time away from making what the customer actually wants/needs
- Don’t add features in the middle of the project unless you absolutely have to
As you can see, I learnt a lot and I’ve probably managed to still miss some things! I really cannot reccomend seeing these speakers enough, so if you’re lucky enough to get the chance to hear them talk, take it!
Danny
dannybrown.blog 