On deployment
My favorite question to ask a software development team is "how do you do a release." The mechanical steps, the culture of how it's done, how they evaluate success, how they cope with failure. You can tell a lot about a company from their deployment flow.
How fast do they iterate? Certainly no faster than the time it takes to release. And most likely, the release overhead is considered "minor." Minor with respect to what? Usually, whatever is used as a development cycle. I haven't met anyone who would do a day-long deployment every day.
How long does the software sit un-deployed? Does it require weeks of QA?
How worried is the team about a bad release? Can they consistently produce quality code?
How painful are integrations? How often do bugs regress?
How tolerant is the company of waste? Software is generally always getting better or getting worse. Processes are always deteriorating or self-regulating.
Can they tell a good release from a bad one? To answer that question you need to know what the objective of the release was. Do the engineers understand what they are building? Do they measure? Do they believe the data?
These questions often produce fascinating answers. Of course, it's easy to sit outside any team and criticize its failures. That's a waste of time. You can use questions like these to learn about a team and its culture. Mechanical mistakes are the result of human mistakes. One person making a mistake may be a deranged lone wolf, but systematic mistakes are the result of systemic problems. And the same is true in reverse - a lone brilliant coder can build a great widget, but it takes a system of people working well together to produce consistently great results.
After an hour with a team talking dirty about deployment, you'll know.
How fast do they iterate? Certainly no faster than the time it takes to release. And most likely, the release overhead is considered "minor." Minor with respect to what? Usually, whatever is used as a development cycle. I haven't met anyone who would do a day-long deployment every day.
How long does the software sit un-deployed? Does it require weeks of QA?
How worried is the team about a bad release? Can they consistently produce quality code?
How painful are integrations? How often do bugs regress?
How tolerant is the company of waste? Software is generally always getting better or getting worse. Processes are always deteriorating or self-regulating.
Can they tell a good release from a bad one? To answer that question you need to know what the objective of the release was. Do the engineers understand what they are building? Do they measure? Do they believe the data?
These questions often produce fascinating answers. Of course, it's easy to sit outside any team and criticize its failures. That's a waste of time. You can use questions like these to learn about a team and its culture. Mechanical mistakes are the result of human mistakes. One person making a mistake may be a deranged lone wolf, but systematic mistakes are the result of systemic problems. And the same is true in reverse - a lone brilliant coder can build a great widget, but it takes a system of people working well together to produce consistently great results.
After an hour with a team talking dirty about deployment, you'll know.
0 comments:
welcome to my blog. please write some comment about this article ^_^