The comments below are my draft notes for an email I sent to my engineering team. Nothing here is proprietary, or unique. It is collected wisdom that I have acquired from many, many, failed projects; and a few successes.
I started thinking about why there seem to be so many stories that turn out to be icebergs. (Iceberg – A story that discovers to be a lot bigger than what the engineers expect.)
So this list is my top experience with these failures.
- Story designed for super coder scale – Super coders have tendencies to want to work on everything in full feature pieces. It worked when they were the solo-engineer, but this is a really bad habit in large projects in large teams.
- You can help stop this by asking about all of the moving parts. Look at code. Get the team to look at code. Stop assuming that Its scaled correctly. It is better to break a story down early, than it is to try to shove icebergs through and realized it won’t be completed.
- If you don’t look at the code being moved, and where it is being moved to, then you really don’t have a plan to change from the legacy architecture to the new architecture.
- Unless you understand where things are moving to, then all parts and targets are moving targets for you. Look at code before or during refinement.
- Understand the frameworks and architectures.
- If you haven’t already been onboarded into the new project, then get onboarded. Schedule with the product specialist or lead, and just do it. Especially when the new architecture is LARGE compared to the old one.
- Understand what the end game looks like. If you don’t have a clear perception of what the end game looks like, then you are coding blind. Request a 2nd and ongoing onboarding sessions to help keep perspective.
- Grab training material from MS and other sources. The more you know, the easier it is to read code.
- Be fearless
- It is better to work on a story and fail, then it is to never work on it. Failure means you have an opportunity to learn. Success means you learned something.
- Act like the vision of yourself as you want to be seen, not the vision of yourself when you think you are stumped. We are in the industry that has the highest number of people with “fraud syndrome” and they get paralyzed by it. Fraud syndrome is common for an engineer that cannot figure something out. This is why I keep talking about pair programming. Get that second set of eyes on the code. What is worst thing that can happen, you fail, and learn? Sounds like an exciting thing to me. Run with it. Don’t make room for that syndrome. Make room for picking apart the code and reverse trace from the public faces to the back end.
For the record, I suffer from Fraud Syndrome regularly. So I get a bottle of tea or brew some coffee, then kick that thought in the backside, and get back to work.
I hope this helps. This should lead us to practices that prevent us from having icebergs and rollovers going forward.