In my last job we hired a guy who had won TopCoder competitions. I expected him to pump out code fast. Instead he turned out to be the most careful, painstaking programmer I have ever worked with. Sometimes it seemed like he was taking longer than necessary, but in two years, as far as we knew, he never shipped a bug. Seriously: no bug was ever found in code he had signed off on.
It depends on the situation, of course. Sometimes you have to "move fast and (risk that you might) break things". I think the "compleat" programmer should be able to work anywhere on the spectrum from fast to careful, depending on the task. But I certainly spend most of my time on the careful end, and I generally prefer to work with others who do too.
Curious: what domain do you work in? In mine (consumer webapps, and now consumer mobile), "never shipped a bug" is a meaningless phrase, because "a bug" depends on how millions of consumers respond to it, and very often code that is deliberately buggy from a technical POV (dropping data on the floor, for example) actually ends up with better metrics.
I used to work in financial software, where things were very different, and before that I'd interned at a company that did avionics software, which is a whole other ballgame. I just find it interesting that the definition of "bug" can vary so greatly across domains in what's commonly thought of as a single industry.
For the term to be meaningful, 'bug' needs to be more tightly defined - a discrepancy between the specification (both as stated and intended[1]) and the actual behaviour of the code is a bug. Now, if the wrong behaviour is actually beneficial, then there's nothing wrong with changing the spec, that's basically the central idea in agile - but the idea that if given a spec to make the blue button green, you make the button green - and if users then react negatively to that, then that doesn't mean you shipped a bug in any meaningful sense. It also doesn't mean you shouldn't change it back, quickly, but the developer did not ship a ship.
1: Just because the specification doesn't specifically state "shouldn't crash if the user inputs a negative number", it's understood that the program shouldn't crash given any user input.
I'm young so this may get better with time but I've had a hard time finding environments that support the slower style. It's often derided as being the "waterfall" method.
Waterfall is a theoretical idea that sounds nice, but fails miserably in practice - the key problem being the assumption that if you are diligent enough at collecting the requirements and constraints, you can resolve them at the design and implementation stage. The reality is that there is never enough time/information/budget/knowledge/resources to map the requirements and constraints, and furthermore, those change all the time so even in the unlikely case that you have managed to map the territory, by the time you deliver the solution, the territory has changed.
One can argue theoretically for waterfall as much as they want (and in fact some people do), but the collective experience with waterfall is so abysmal that whoever wants to waterfall needs to argue against the failures, rather than for the method.
I'm not aware of any large scale projects that were attempted using Agile. Are you? FWIW, I don't think Agile is the answer - there's a continuum between (and beyond) waterfall and agile, and it's not one-method-fits-all anyway.
For that matter, I can hardly think of large scale software projects that succeeded in the sense that they were on time, on budget, and satisfied the requirements a-posteriori, regardless of methodology.
Regardless, how many projects that people here are involved in are really large scale ?
I'm not defending agile, but what is described in the abstract cannot fit with what I am familiar with as "agile" - an almost defining quality of an agile process (as I was introduced to it) is that at any given moment, the status of the project is transparent and well known by all stakeholders. Thus, if you discover all of a sudden that the project is late and over budget, you have been sleeping at the wheel.
(Note: This is not a "no true scottsman" argument. And I honestly think agile is only a good match for some projects, and not e.g. infrastructure. Nevertheless, this does not sound like the "agile" I know).
Hello from a dev manager in a big enterprise! My personal experience after working in an org where the PMO tried to force waterfall and the devs tried to force "agile" is that the key to success has nothing to do with project management methodology and everything to do with 1) interpersonal relationships, and 2) the technical team having adequate domain knowledge to make good decisions while planning and executing on the project/product. Lack of #2 is why many corporations force waterfall -- because they can't or don't trust the dev teams to make intelligent choices, and/or because the business stakeholders can't be bothered to engage with them on a daily basis. It's pure laziness and lack of respect for the software that drives processes.
I'm going to chime in that "slower" and "waterfall" are also orthogonal, but discuss it from a completely different point (hence not replying to that comment).
Agile, done right, -can- (and I'd argue, -should-) be slow, in the context of what this is talking about. 'Slow' doesn't mean delaying working on coding until all requirements are defined (i.e., waterfall), it means once you start working, to make sure you've thought about it, to make sure you're careful in your implementation, that you pause and think about what you're doing, don't just breeze over edge cases or possible error conditions.
You can think slow or act fast even given one requirement. Say I have a requirement, "I need a REST endpoint that gives me X information".
The fast approach is to just say "Okay, this is getting information; that's a GET. We've already been writing this in this language and framework, let me just stick a new endpoint in the router file that gets that info and returns it".
The slow approach is to say all of that, and then follow it with "Okay. What happens if this information isn't there? Can that happen? If something goes wrong, do I need to return a sensible error message along with the HTTP error code? Does the consumer understand a specific kind of error message, such that it will be displayed to the user? As part of getting X, are there any additional parameters that we need; i.e., is it enough to get -all- Xs for the call, or is the size of it likely to be enough to warrant getting just Xs that match (filtering criteria)? Does the DB need to be optimized for that sort of query?" Note that agile -does- mean you probably don't address all of those as part of this story; KISS, YAGNI, etc, still apply. But taking it slow means you -think- about those things.
What's the difference, if it doesn't lead to any change? Well, thinking about it means you likely cause any failures to fail gracefully, in a well defined, recognizable, predictable manner. It also likely means you've brought up those issues, and you can determine whether they should be tackled at all; you might be able to do them as part of this story if they're small, or add some hooks such that it'll be easy to add them later, but it might also lead to creating new stories, that get prioritized into the next sprint.
Now, while people argue you need to move fast and break things sometimes, I'd argue that taking things 'slow' like that -is always better-. Why? Because if you take things slow, you can still choose not to do something. The overhead of just thinking about it, and then actively choosing to take the fastest path, is very, very small compared to just rushing in to do the fastest path. Maybe 10% extra or so. But as often as not, taking it slow will lead to you coming up with additional work that you really need to do; without it your app will fall over, or your users will get pissed off, or whatever. While that then feels slower (you are, after all, doing more), it's getting things done that -need to be done-. If you'd taken the fast approach, you'd realize you need them later, but in hindsight would justify moving fast because "well, we didn't know that then, and we got features out the door". Sure, you didn't know that then because you -didn't pause to think about it-. You can't claim that you couldn't have predicted it, and moved to avoid it, because you never tried to predict it. If you -did- spend some time thinking, and fail to catch something, then you really couldn't have predicted it, because you -tried- to. You've optimized for the best possible path as you can understand it at the time; taking the fastest path may or may not land you there, and you can't know whether it was optimal.
In short, moving fast means defaulting to not doing the extra work; moving slow means thinking, and actively -deciding- what level of work needs to be done. You can be nearly as fast as 'moving fast' (by thinking about it and deciding you don't want to do the extra stuff), but you can also decide that certain tasks really need to be done, and that, while making you slower, leads to a better product.
> latent defects frequently have a long shelf life
They do, but it has also been observed that code in which no bugs have been found is less likely to harbor them than code in which some bugs have already been found and fixed (other things being equal, of course).
If I had had to bet where in the whole codebase the next bug would turn up, I certainly would not have bet it would be in this guy's code.
It depends on the situation, of course. Sometimes you have to "move fast and (risk that you might) break things". I think the "compleat" programmer should be able to work anywhere on the spectrum from fast to careful, depending on the task. But I certainly spend most of my time on the careful end, and I generally prefer to work with others who do too.