a few threads...

Family is dealing with illness, Z got us started, then Amy and I might be getting hit as well. Tried to take a nap this afternoon while Z slept. Mostly worked, had a few thoughts I wanted to try and follow up on. Budding them here, to drive further later.

- Managing requirements for a project is a lot like managing clutter. Few ever say "I want to have 36 McDonald's Souvenir Cups with Grimmace." Much the same way no one asks for a project to come in over budget and late. But scope creep is just like clutter, it starts by reacting to a desire, rather than working towards a vision. Just because you want something doesn't mean it has a place in your life(for clutter)/project.

Now there is something to be said for the vision changing and growing, but at key points when you're starting to grow you vision statement, then you need to stop and reevaluate your project. Is it the right place to grow, or is it better to start a separate project. Sometimes the right thing is to grow the project. Some times not. Growth is a natural process that works within the process of Supply and Demand. Growth that is uncontrolled tends to be bad. Cancer is unrestrained growth of bad ideas.
There is something to be said for dealing with the principles of simplicity and good architectural practice. There is something slightly disturbing about parallels between projects at work and episodes of Clean Sweep. :)

- In starting a project, I am increasingly seeing the need to capture a vision statement. It sounds all hokey and typical management bs, but at the end of the day, if you can't explain a simple vision of what you're trying to do, that probably means, you don't know what you want to to do. Once you have a vision you need to look at Strategies and Tactics. Strategies are the steps you need to take to meet your vision. Tactics are the actions you take to implement your strategy.

- The care and feeding of a project are not hard rules to figure out. It kinda goes along with keeping healthy. The rules are simple -- eat a balanced diet and exercise regularly. Screw with either of those options and the risk of bad things happening grows. Compare with a project-- you want to make sure you're getting the right inputs -- requirements, funding, approvals, and the right actions -- clearing technical debt, quality control, doable benchmarks and voila -- project success.

- Often projects come in like the patient who comes in with a gunshot wound and finds out they have a heart condition. If you don't deal with the gunshot wound, the patient dies. If you fix the gunshot would, and neglect the long term care necessary to treat the heart condition, well, the odds to not stack up in their favor. In a crisis, triage is important, and getting the biggest wound out of the way is critical, but unless the long term behavior of the project changes, the project is doomed anyway.

-- Perhaps that last example would work better thinking about a patient with a heart attack or stroke. You have the immediate crisis, but long term care and change are necessary to improve.

-- The hardest job as an architect is figuring out what the problem the customer needs to solve is. Finding out what their problem is, when most of the time they can't express the nature of the problems, only a glimpse of the ideas they had. Started reading "The Not So Big Life" by Sarah Susanka. I suspect there is a good bit of learning I can do as a software architect from reading from construction architects.

As an aside, we're in the process of de-cluttering our house. With Z soon to be on the move we want to give her a safe and friendly place to move through. In examining my own relationships to my stuff and my space, I'm learning a lot about my stuff and myself. Highly recommend reading "It's All Too Much" by Peter Walsh. Very useful if you're wondering why things get so messy.