Recently in software engineering Category
Agile Advice recently posted a link to an old (1996) article from Fast Company discussing how software for the Space Shuttle is produced.
The article profiles the people who write the code and their methods, and bullets out some of the axioms by which they work.
One of the more interesting tools is a program that calculates how many errors should be present in a given release. Then, even if things look ok, they keep testing until they hit the predicted bug count.
Like computer models predicting the weather, the coding models predict how many errors the group should make in writing each new version of the software. True to form, if the coders and testers find too few errors, everyone works the process until reality and the predictions match.
At times, the article chastises us young punks for dressing down and writing buggy code. While I alway appreciate a dose of humility, I think there's a big difference, both in budget and goals, between launching a REALLY expensive rocket with people in it into space and rolling out a cool new web search.
Nonetheless, it's a very interesting read, and worth the time.
[link] They Write the Right Stuff
I'm sure many people have hit upon this realization before I, but bear with me, I'm slow.
These two statements are completely incompatible:
- The end of the project the WORST time to change the design or refactor code.
- The end of a project is when you BEST understand the problem, and can produce the optimal solution.
As your project reaches the endgame, you want to be putting on the final touches. Fix bugs, performance test, get your deployment ready. Changing things, even slightly, can introduce wobbles and instability. The last thing you want is for things to be "good", then do some refactoring that breaks features that have been built and tested.
Sadly, by the end of the project you've also become an expert in the space of the particular problem you're solving. You can see flaws with the initial design, and ways to make the code more maintainable. If you had these piercing insights near the start of the project, it would be great; you could go refactoring everything without pissing anyone off. But at the end, things are delicate, and all you end up doing is saying things like "Ooooh, we TOTALLY should have done that part like THIS".
I suppose this is an argument of scrum-style iterations, where there's almost always a Next Time, and it begins with refactoring the existing solution.
The alternative is to never go back, and in doing so condemn all future peeps to maintenance hell.
Promoting a release of code to test is like sweeping up after a dirty job. You need to clean out all the bugs, and when you think you're done, go back and check everything again.
Back my formative high-school years, I worked summers as a landscaper. It was really messy. Dirt, mulch, sand, etc. By the end of a job, the customer's driveway would be covered with crud.
As a rookie, my job was to sweep up. So, I worked really hard my first time and swept the drive completely clean. I had done a masterful job. Not one speck of sand escaped my speedy broom.
"Good.", said my boss. "Now sweep it again."
To my surprise, the extra sweep picked up a small but substantial pile of dirt. I had been convinced I was done, but there was in fact a teeny bit more to do.
I think deploying software is like sweeping up after yard-work. You scrub all your bugs, marking them complete as each is committed, but in the end everything still needs at least one extra sweep before promoting the lot.
I'm always a little surprised at what kind of things can go wrong, even when every ticket in the batch is marked "fixed".
Jurgen recently posted on why we should chuck our burn-down chart in favor of the better, faster, stronger burn-up chart. I agree with the facts of the case: burn-up charts reveal more information. But, I don't want to kiss my burn-down chart goodbye just yet.
I'll admit that I've started using burn-down charts only recently, so I can't speak from a volume of experience, but my favorite thing about burning down is the simplicity: Make the line go down. If it's not going down and aimed at the target, something is wrong.
I use it as the proverbial canary in a coal mine. It signals when things are off-track. Then it's up to me to track down why they're off. We may have discovered new tasks, features might have been added (scope creep), or there's some obstacle to our progress. I'm not looking to the chart to tell me why things are off, just if they're off.
Don't get me wrong. Someday I'd love to be at a point where I could create and use a burn-up chart like this, but for now, all I can manage is the stark good/bad of the burn-down chart.
I'll admit that I've started using burn-down charts only recently, so I can't speak from a volume of experience, but my favorite thing about burning down is the simplicity: Make the line go down. If it's not going down and aimed at the target, something is wrong.
I use it as the proverbial canary in a coal mine. It signals when things are off-track. Then it's up to me to track down why they're off. We may have discovered new tasks, features might have been added (scope creep), or there's some obstacle to our progress. I'm not looking to the chart to tell me why things are off, just if they're off.
Don't get me wrong. Someday I'd love to be at a point where I could create and use a burn-up chart like this, but for now, all I can manage is the stark good/bad of the burn-down chart.
It's hard to help someone realize their vision for software and the web. Finding out what clients really want is hard, especially when you need to do it over email.
After going through this a handful of times, I've come up with a pair of questions I ask anyone who wants help with a site. The answers (or non-answers) reveal what a person wants, without being overwhelming:
Question two goes a long way in aiding in design. It cuts out a great deal of the back and forth that would happen if we just sat in a chat going "so what do you want?", or showed a slew of artsy fartsy "concepts".
After going through this a handful of times, I've come up with a pair of questions I ask anyone who wants help with a site. The answers (or non-answers) reveal what a person wants, without being overwhelming:
- In ten words or less, and with as little technical language as possible, what is your goal?
- What sites do you like?
Question two goes a long way in aiding in design. It cuts out a great deal of the back and forth that would happen if we just sat in a chat going "so what do you want?", or showed a slew of artsy fartsy "concepts".
It's amazing what you can do with answers to just these teeny questions. You'll be 75% on your way to making your client happy.
I've often asked "How do we know when we're done?" in requirements meetings. It gets people to crystallize what they want and keeps me focused on what's important.
Any stopping point in software is artificial and arbitrary. There will always be more to do. Features can always be improved. It's why we all have jobs.
The essence of "when do we stop" is really "what is the minimum result that will satisfy your needs?". The minimum is faster. Time is money. The minimum is valuable.
The human brain has a problem with this, and folks balk at accepting anything less than complete victory over a problem. However, reality and economics (surprise! they're joined at the hip) dictate that we focus on the simplest possible solution first. Speed is the key.
A recent revelation for me has been that I don't spend eight hours a day programming. This was a shock. For a long time I was estimating my effort as if I was spending every minute of the work day slinging code. If I estimated a project at forty man-hours, I would figure eight hours a person per day and do the math from there.
The simple truth is that you don't work on a task for eight hours a day. I'd hazard to say that at best, you can do four.
It is impossible to convince people of this fact.
We like to think of ourselves as hard workers. We take pride in our dedication. How dare anyone suggest we're giving less than one-hundred percent? Ego gets in the way, even in the best-intentioned of people.
I know you don't believe me. Thankfully, you don't have to. Grab yourself a trial version of TimeSnapper, fire it up on a Monday, and forget about it for a week. On Friday, play back your days and see just how much time you spend productively coding. I'll guess it's not as much as you thought.
It's ok to cry. I went into denial when I first saw my results. I tried to convince myself that the recording was wrong, and that I was spending more time writing code than the machine itself had recorded. In the end, the truth set me free. A lot of time goes to meetings, discussions, fire drills, random tasks, email, and the internet. Not to mention task switching.
My absolute maximum task dedication is three or four hours of coding on a single project a day; and that's a day without scheduled meetings and few formal interruptions. While a little depressing, this is useful information. When it comes time to estimate development for a new project, I know not to budget eight hours a day.
In the end, knowing where your time goes makes it easier to spend it wisely.
The simple truth is that you don't work on a task for eight hours a day. I'd hazard to say that at best, you can do four.
It is impossible to convince people of this fact.
We like to think of ourselves as hard workers. We take pride in our dedication. How dare anyone suggest we're giving less than one-hundred percent? Ego gets in the way, even in the best-intentioned of people.
I know you don't believe me. Thankfully, you don't have to. Grab yourself a trial version of TimeSnapper, fire it up on a Monday, and forget about it for a week. On Friday, play back your days and see just how much time you spend productively coding. I'll guess it's not as much as you thought.
It's ok to cry. I went into denial when I first saw my results. I tried to convince myself that the recording was wrong, and that I was spending more time writing code than the machine itself had recorded. In the end, the truth set me free. A lot of time goes to meetings, discussions, fire drills, random tasks, email, and the internet. Not to mention task switching.
My absolute maximum task dedication is three or four hours of coding on a single project a day; and that's a day without scheduled meetings and few formal interruptions. While a little depressing, this is useful information. When it comes time to estimate development for a new project, I know not to budget eight hours a day.
In the end, knowing where your time goes makes it easier to spend it wisely.
I caught an episode of Gordon Ramsey's Kitchen Nightmares tonight on the wisdom-box. Being the 37Signals Fanboy that I am, I was on the lookout for what Gordon could teach me about building software.
Right away I noticed the staff's resistance to Gordon's redesigned menu. He threw out the old seafood roster and changed everything over to hardcore steakhouse in a couple of days.
I realized that I tend to have a similar view of drastic changes in software:
Gordon ALWAYS nukes the menu and starts over. If things are bad, or if you really want powerful change, incremental improvements won't cut it. At some point, you're going to need a big bang. It will probably hurt.
Right away I noticed the staff's resistance to Gordon's redesigned menu. He threw out the old seafood roster and changed everything over to hardcore steakhouse in a couple of days.
I realized that I tend to have a similar view of drastic changes in software:
- "Isn't that risky, doing all of that at once? Why don't we just do a small part first to see how it goes, hmm?"
- "We really don't need another big bang project. They're hard to do, and they're always late."
- "Let's just evolve existing features, instead of always blowing them away and starting from scratch"
Gordon ALWAYS nukes the menu and starts over. If things are bad, or if you really want powerful change, incremental improvements won't cut it. At some point, you're going to need a big bang. It will probably hurt.
This meeting smell happens when someone from the technology team asks "Do you want...".
"Do you want the user's session to continue after they leave the site?"
"Do you want us to optimize that for search engines?"
"Do you want auto-complete in the search box?"
These are bad questions because they don't convey what's really being asked: "Is this feature worth our time and effort?".
What the business owner hears is "Should we include this sweet feature that will make you look good?". Their answer is almost certainly yes, but they're not answering the real question.
The real question is "How important is this feature?" This conveys the idea that the tech team wants to focus on essentials. It also reminds the business owner that not all features are created equal.
I wrote before about how stating "I want" is a good smell. The difference is that it's OK for the business owner to declare "I want", but not ok for someone to ask "Do you want?". It's leading the witness.
Every time you ask someone if they want an awesome feature the answer will be yes. The real information comes when you ask how badly they want it.
I saw a flamebait of a post today that's fairly critical of the agile direction software development is taking .
Finishing it, I realized that it was either some kind of sarcastic rant or egotistic power trip, but it got me thinking. Doubting, even.
"Why is Agile Better?", I asked myself.
Why do managers allow technology groups do a 180 on how they build things? I mean, imagine if a construction company told you they were going to build and finish your house a single room at a time. You'd probably punch them in the face.
I started doubting myself.
"Maybe traditional waterfall monolithic IS the better way."
"Maybe we're just lazy wimps".
"Maybe agile is just a fad, like Hypercolor".
Finally I took a deep, calming breath. I remembered why managers let us do agile-ish things. Risk.
Risk is what convinces managers to do agile, whether they know it or not.
I'm not saying there aren't other good reasons, but no manager is truly concerned with your personal comfort while programming. They don't care how happy you are or how bleeding edge your methodology is. They only care that the project is done on time and that their boss is happy.
I'll prove it. When was the last time that you had a looming deadline and your manager said, "Aw, let's just move the live date back a few weeks. I don't want you getting all bent out of shape and stressed out. Your comfort is more important than a silly deadline"? It's a manager's job to care about results, not comfort or fun.
Arguments about "It's more in tune with how people work", or "It's nimble", don't really resonate with managers. But risk, there's something that makes their ears pick up.
Managers love to manage risk, and agile helps. It lowers the chances of a live date arriving with nothing ready for launch. Agile helps get the most important parts production-ready first. If the entire development team is struck by a single Bus Of Doom and wiped out, the project can still launch with the highest priority features complete. This gives managers warm fuzzy sensations they aren't used to feeling ( because of the risk avoidance part, not the dev team being wiped out ).
Classical waterfall stinks at mitigating risk. Everyone has experiences to back that up. The project that's perpetually 90% complete. The Case of the Missing Fifty Pages of Requirements. The Gotcha from Hell. All these are cases where the big day comes around and there's absolutely zilch to show for it. That's risky.
If you have a superninja waterfall strike team, then waterfall might be just the thing for you. If you're like every shop I've ever worked for or heard of, you're praying for some agile, any agile, to kick in and save you. I say play the risk card and see if the managers take the bait.
Finishing it, I realized that it was either some kind of sarcastic rant or egotistic power trip, but it got me thinking. Doubting, even.
"Why is Agile Better?", I asked myself.
Why do managers allow technology groups do a 180 on how they build things? I mean, imagine if a construction company told you they were going to build and finish your house a single room at a time. You'd probably punch them in the face.
I started doubting myself.
"Maybe traditional waterfall monolithic IS the better way."
"Maybe we're just lazy wimps".
"Maybe agile is just a fad, like Hypercolor".
Finally I took a deep, calming breath. I remembered why managers let us do agile-ish things. Risk.
Risk is what convinces managers to do agile, whether they know it or not.
I'm not saying there aren't other good reasons, but no manager is truly concerned with your personal comfort while programming. They don't care how happy you are or how bleeding edge your methodology is. They only care that the project is done on time and that their boss is happy.
I'll prove it. When was the last time that you had a looming deadline and your manager said, "Aw, let's just move the live date back a few weeks. I don't want you getting all bent out of shape and stressed out. Your comfort is more important than a silly deadline"? It's a manager's job to care about results, not comfort or fun.
Arguments about "It's more in tune with how people work", or "It's nimble", don't really resonate with managers. But risk, there's something that makes their ears pick up.
Managers love to manage risk, and agile helps. It lowers the chances of a live date arriving with nothing ready for launch. Agile helps get the most important parts production-ready first. If the entire development team is struck by a single Bus Of Doom and wiped out, the project can still launch with the highest priority features complete. This gives managers warm fuzzy sensations they aren't used to feeling ( because of the risk avoidance part, not the dev team being wiped out ).
Classical waterfall stinks at mitigating risk. Everyone has experiences to back that up. The project that's perpetually 90% complete. The Case of the Missing Fifty Pages of Requirements. The Gotcha from Hell. All these are cases where the big day comes around and there's absolutely zilch to show for it. That's risky.
If you have a superninja waterfall strike team, then waterfall might be just the thing for you. If you're like every shop I've ever worked for or heard of, you're praying for some agile, any agile, to kick in and save you. I say play the risk card and see if the managers take the bait.
