Deployment readiness

Deployment readiness

Have you ever seen this development cycle?

  1. Install new build
  2. App doesn’t start, doesn’t log any error why
  3. Go back to source code and add improved logging
  4. Install new build
  5. Read logs
  6. Fix the actual problem (usually some stupid configuration thing)
  7. Repeat steps 1-6 until all bugs are gone

Was it because of your code, or someone else’s? This sort of cycle is time consuming, frustrating, stressful, and makes you look helpless (or like a cowboy) in front of project managers and support staff.

If your app can’t produce logs your infrastructure staff can understand, then your app is not even close to production-readiness. If it doesn’t log clear errors, how can anyone hope to deploy and support it?

RSS: What I’m reading

RSS: What I’m reading

Lately I’ve had a few people asking for resources and links to articles about TDD and DDD. I’m a big RSS junkie, so I thought I would just share the feeds I’m currently reading.

I mostly read programming blogs, but you can see a few hints of my hidden UX aspirations as well 🙂

  • 456 Berea Street
  • A List Apart
  • Ayende @ Rahien
  • CodeBetter.Com – Stuff you need to Code Better!
  • {codesqueeze}
  • Coding Horror
  • Coding Instinct
  • Devlicio.us
  • DotNetKicks.com
  • Hendry Luk — Sheep in Fence
  • HunabKu
  • James Newton-King
  • Jimmy Bogard
  • Joel on Software
  • Jon Kruger’s Blog
  • jp.hamilton
  • Lean and Kanban
  • Los Techies
  • Paul Graham: Essays title
  • programming – top reddit links
  • Random Code
  • Scott Hanselman’s Computer Zen
  • Scott Muc
  • ScottGu’s Blog
  • Seth’s Blog
  • Smashing Magazine
  • Thoughts From Eric » Tech
  • Udi Dahan – The Software Simplist title
  • UI Scraps
  • UX Magazine
  • xProgramming.com
  • you’ve been HAACKED

Agile: convincing stakeholders

Agile: convincing stakeholders

Yesterday I attended BarCamp Agile Wellington, and although I had to leave early, I thought the event was a great success.

In keeping with the theme of BarCamp I thought I’d share my notes from one of the sessions: an unmoderated group discussion on Agile advocacy in large organisations, and how to convince stakeholders to adopt it.

Problems

  • Unfamiliar jargon.Terms like Agile, Scrum and Extreme Programming can be unfamiliar and scary to those who don’t understand them. What was wrong with regular programming?
  • Agile can’t guarantee certainty. A CIO’s job is to manage risk, and having watertight specifications locked down before projects commence is one way to combat it. Agile may appear riskier by leaving too much room for change, particularly in the public sector.
  • Getting the customer on team. Heavy time commitments and taking a burden of responsibility for the project’s success may not be attractive to customers.
  • Agile is not about playing cowboys or cutting corners. Agile is actually more disciplined than traditional waterfall-style frameworks.

Solutions

  • Hold the jargon, please. Don’t mention Agile, Scrums, Extreme Programming, or the Agile Manifesto by name. They aren’t really that important anyway. Perhaps ‘Agile: Everything but the name’ would be a good mantra to adopt?
  • Agile produces a self-managing team. With greater involvement from team members and customers, the traditional project manager role becomes redundant.
  • Lock it down. Sell a fixed timeframe with a fixed budget, but leave the scope open. Focus on the overall end result of the project rather than individual requirements. This way the size of your project box will be limited, but the blocks that fill it can be swapped and rearranged as you go.
  • Sell it inside out, from the bottom up. Instead of trying to convince CIOs about Agile (who more-likely-than-not will see any change as risk), focus on the people who will actually use it. Change and new ideas are interesting to developers, but scream risk to stakeholders.
  • Don’t tell upper management. Do they even need to be aware about Agile before it can be used? Do they even know what current frameworks their organisations use? Trying to convince them on the benefits of Agile may be a complete waste of time. Sell them on completion of a successful project instead.
  • Just get on with it. Why bother convincing people about Agile at all? The evidence is there, so just get on with it!