code development programming

Slides and Mind Maps for DunDDD

DunDDDAs promised, here’s the slides and mindmaps for the sessions I was involved in at DunDDD 2011. The Mind Maps were generated using FreeMind.

The Philosophy of Code

This talk was an experiment on my part, given the knowledge I’ve picked up from reading books and articles from some of the smartest people in the business and beyond, and I wanted to share some of that. As Gary Park noted, it still needs some polish, but I think there’s a good idea in there, so I hope to get another chance to present it in the future. The presentation itself is licensed under creative commons, but please pay attention to the photo attributions if you want to use them in your own work. I’ve also included a link to the original mind map which contains many more great quotes.

Google Docs : The Philosophy of Code

Mind42 : The Philosophy Of Code

Download The Philosophy Of Code Mindmap (.mm format)

Software Requirements

The original presentation was given by Craig Murphy (on Twitter as @CAMurphy) and is available here : Open Discussion on Software Requirements

The mind map generated from the discussion is reproduced below.

There was a good discussion of how requirements can have different levels of detail and how the methodology can shape the process and the documentation, as well as the change process. A bit of waterfall vs. agile, but each has their place.

Mind42 : Software Requirements

Download the Software Requirements Mindmap (.mm format)

How The Web Was Lost

This talk drifted a little, since we agreed fairly quickly that with the demise of Flash and Silverlight, and the rise of the web-powered desktop in Windows 8, the web has in fact won. +1 for open standards. But where does that leave the behemoths like Apple and Microsoft who have benefited the most from the traditional role of the desktop. Can they keep developers and users on their platforms, or will they be lost to cross-platform development?

Mind42 : How The Web Was Lost

Download How The Web Was Lost (.mm format)

code development lifehacks programming

Agile Is Dead

As a follow up to DDD Scotland 2011, I want to thank everyone who joined in. It’s time to reveal my ulterior motive : I did it all so I could get a blog post 🙂 So thanks to everyone who helped write the Agile Is Dead Mind Map – please feel free to join in the discussion below.

Agile’s been bouncing around in my head for a while given that it’s reached its tenth birthday, and a lot of people are talking Agile, but its not the agile I see in The Agile Manifesto. It’s a silver-bullet snake-oil leech that throws out agile words and terminology but without the guts to actually make agile work. It’s an agile that doesn’t challenge managers or clients, that sticks to deadlines and a list of features, but promises faster, cheaper development.

It doesn’t work.

And don’t call it agile.

Agile works when the customer understands that it’s an interactive process, when there is a functional feedback loop and when the plan is flexible enough to adapt to changes by dropping features or extending deadlines. If you’re not doing that, you’re not agile.

But, you can be successful without being agile, you can do functional testing, you can have a CI server, you can do team priorities, and stand-up meetings. But until you have feedback loops, for each developer, for each feature, and for the project, you’re still playing the old game. It’s an easier route. It’s more comfortable for everyone to have a defined role, for everyone to work from a fixed position. And that’s fine. Just don’t call it agile.

Procedures and tools provide comfort, I know that, you know that. Budgets drive your business, procedures help you budget, and procedures mitigate risk. If it’s signed off, it’s not your fault. But then, someone must have signed off the Ariane 5 too. Would you rather deliver software or paperwork? Is paperwork your protective shield?

If you’re a manager, do you trust your developers? Do you trust them to take decisions, to talk to the client, to deliver professional quality? As a professional developer, that’s the teams I want to work in, and I feel privileged when I get that chance, because those projects always work out smoothest in the end, although they can be the hardest to set up.

If you’ve tried agile and failed, did you really try it? Did you trust the developers to deliver, did you trust your manager to keep things running, did you trust the client to give you the feedback you needed? Did you trust yourself and your team to be honest?

Agile, the word, has been hijacked. It’s dead but still walking. What matters is the philosophy behind it. And it’s not easy. No profession is. Are you a professional or an unskilled cog in an assembly line?

I don’t give easy answers. I wanted to become a developer because the thing that drives me is solving problems. And these aren’t problems that stay solved. HTML 1.0 didn’t solve everything, that’s why we have HTML5. Project management is a problem you need to solve on every project. Every project you’ll learn something new, and you’ll face new challenges. I cannot prescribe a solution, because I don’t know your project, and that’s how agile works. You have to adapt to your surroundings. After all, you’re only human.

If you want to be agile, talk to your team, and don’t let your ego stifle peer reviews, paired programming or feedback sessions. And if anyone does let things get in the way, staple a copy of the Agile Manifesto to their head and blow raspberries at them. Or go and find out about Programmer Anarchy and ask if you or your team could cope with self-directed project management, just like anyone volunteering for open source. If not, why not?