I’m doing a lot of writing design guidelines at work right now — essentially codifying in words the things we’re already doing. Paving the cowpaths if you will.
My June 28 post on The Interconnected is about where to put design guidelines when you write them, what application to write them in, what to put in them, and why nobody’s going to read them but you.
Read Back to Basics: Writing Design Guidelines on The Interconnected
Alex Duloz, who was one of the brains behind The Pastry Box, asked me to participate in his 2017 project The Human In The Machine. He’s doing a look at productivity and how we handle it, with a post every day about productivity from a different author.
For my post, Preconditions, I thought about my daily routine and what things I do to set myself up for a productive day. Some of them are physical and environmental, like the way my desk is set up or how warmly-dressed I am. Others are about the work itself: is it ready to be worked? How do I know? The list goes on from there.
I don’t have any expectation that anyone else will use my process. More, it was nice to quantify the process I’m using and see it out on paper (well, electrons) so I could confirm it. And a little bit, writing it down helped me look at it and decide whether everything really was of value.
The last of my three rants about Big Up-Front Design discusses the conditions in which big up-front design is a really good idea.
It’s not always be a good idea to do big up-front design. Conversely, it’s not always a good idea to skip it. Th trick with this technique as with all techniques is to know when to use it and when not to.
I’ve tweeted a couple of times about a project I’m on where we’re doing a big up-front design. It’s a long project.
Every time I have, someone has replied back to me to tell me that if I’m doing a big up-front design, I’m not doing Agile correctly and I’m going to get burned.
Outside of the fact that it’s incredibly rude to tweet someone and tell them that their process (which the vast majority of us working in big companies get no control over) is wrong, there’s a problem here: there’s nothing wrong with big up-front design.
Explaining why front-loading a development process with a design process has been more difficult than I expected. My first draft was long and rambling. Turned out I really had three posts hiding within it.
My October 7 article for The Interconnected, Doing Agile Wrong: Design is not Development describes the difference between Agile and UX. It’ll be followed by an article on the difference between big up-front software design and big up-front product design. Then sometime after that, we’ll post the final article, which explains when big up-front (product) design is right for a project.
My September 20th post for The Interconnected, Two lessons, more than two bricks, discussed estimating software, stubbornness, and eleven tons of bricks.
My design estimating skills are pretty solid. My landscaping estimating skills? Not so much actually.