Hey lover, you might want to check out a linguistic construct known as implication. The implication here is, of course, not that he's going to crush the knowledge out of his skull, but that he's giving up on utilizing it in his job.
For the same reason all the steps in XP that are explicitly called out weren't happening naturally I suppose.
is a pretty different thing than saying, "XP has a fundamental flaw."
I didn't say that XP has a fundemental flaw. I said, in fact, that the testing first thing was good. I implied that iteration was good. I believe in a large number of the XP constructs. In fact, off the top of my head I don't know what they have that I would argue is wrong.
However, I do think it is incomplete.
I'm glad you think it's perfect. More power to you and best of luck on your projects. I find it to be insufficient for large scale projects without some additional, explicit, steps to build a coehesive whole.
Second, because a "proper up-front design" is amazingly difficult to get right, takes a long time to get right, and, if you can reach that point iteratively anyway, doesn't add as much business value as delivering a couple of iterations worth of software in the same time period.
We're close to agreement here, but let me just belabor this one additional post.
I'm not arguing for up-front design. As you rightly point out, it is amazingly difficult to get right. Perhaps impossible even as your second point is equally well taken. Requirements change and therefore the design will also.
I'd just like to see the XP movement embrace medium and high level design as an instrinsic feature of the methodology rather than an implicit fallout of some of the work done.
You claim to be trying to acsend to the level of a "doctor" or "lawyer" yet you can't parse a paragraph sufficiently to understand my point despite the use of intentionally vague terms.
There are many kinds of engineers involved in construction my man.
i think that you massively underestimate the sacrifice and hard work and effort it takes to become a "real engineer".
You don't know me from Adam. But I see, like so many before you, you've found it much easier to assume ignorance in those that think differently from you.
I suggest that you might want to broaden your horizons and consider that sometimes, maybe often, the person who disagrees with you is as smart and well educated as you are and still finds a different conclusion.
The best part is, I don't even think differently from you. I agree that "real" engineers require a lot more training than most of the folks that call themselves engineers in software.
Architecture should be part of the process. XP describes a process without explicit steps for architecture.
And when you did XP, what architectural problems did your team have without those special rituals?
None. We added the rituals. Each iteration included 'tests' (in the form of human walk throughs) to ensure adherence to design and refactoring of the design itself. Just like the code, we iterated over the design.
While I agree with you that the big win is to have testing regardless of when it's written I have to say that I agree with the XP folks concerning when is the best time.
I've worked on dozens of projects and the only ones that were well tested were the ones with explicitly formed testing groups. The reason for this is simple. Developers know they need to test. Management knows that testing needs to be done. If the testing is not done first, however, it is far too easy to ship the product three months late than to high five everyone and say, "great job, now we just have to spend six months testing and we're golden". The market pressures are quite strong to ship something now instead of doing QA.
There is a secondary issue as well. Development of software it a constructive task. It is very difficult for a developer to spend a month or a year building something and then turn around and do an effective job of trying to destroy it. It is much easier to get into that frame of mind before you've spent hundreds of hours being constructive. The XP folks have this part strongly right.
What's more valuable to the customer after a month - 80% of the functionality in clean, testable code? Or 0% of the code but a big pile of Visio diagrams?
After a month, clearly they will perceive more value in having some code (I quibble with the 80% figure though. Any application that can get 80% of the code written in a month is aproachable using *any* methodology).
After a year or two though. The story changes when you look at the longer term. An application that is properly designed and controlled will have better maintanability than one that was continually refactored into a thousand discrete chunks.
OK, you feel you have found and solved problems before writing code. Fair enough. However, consider how much time you have spent on that non-coding stuff, though, and how much you could have accomplished if you had spent that time writing tests and code.
I write tests and code. I claim that if one adds serious high level design to the XP development cycle that the amount of code produced goes down and, more importantly, the quality of the code goes way up. Perhaps not as important to the people doing the initial development as being told that they can work without thinking and then go back and think about whether they could have done things better, but clearly of great importance to the folks paying for the application. They will be the ones who continue to pay for it during it's maintenance and enhancement phases.
I think the XP folks would agree with you. Nobody is advocating that you don't do design, just that you allow your design to stay flexible in the face of changing requirements.
I know the XP folks would agree with me. I'm one of them in a sense and know many of them.
My objection is that the methodology doesn't explicitly call for it. Therefore, folks paying attention to these higher level issues aren't practicing XP, but something like XP++.
These things should be called out in the core methodology and it isn't.
Arguing is always more fun once you have some facts.
In fact, I've used XP on more than one project, including the one I'm working on now, and am friends with a prominent agile author who taught me about those methods when they were still nascent. So I think I have the facts down cold.
Despite my knowledge of the subject, I think that XP's generally direction is only half good and the lack of focus on higher level constructs is dangerous. If you want to claim that *you* are using higher level constructs, then fine. But you are doing something *in addition* to what XP suggests, which is exactly what I was saying should be done.
Let's say you are a construction engineer and designing a building.
Yes. Indeed, let's say that.
* A building lasts for 30-50 years easily. Software lasts, what, 3 or 4 years before there is a new release significantly improved to justify a new expenditure?
* Buildings require little to no engineering intervention in the intervening period. A typical software project is several orders of magnitude more complex than a typical building. They require constant maintenance.
* Buildings that need new features rarely depend on engineers. For the most part repartitioning of the cubes, or even moving a non-bearing wall, requires no engineering. Software gets new features regularly and requires engineers to get the job done.
So, while I'm a consultant and love it. To say that everyone need be is speculation about what the state of things might be, based on a completely untenable position. Software and building engineers aren't the same and never will be.
Refactoring is improving the design of existing code. Be it 10^1 or 10^6 lines, if you're changing the design without changing the functionality, it's refactoring.
I've never seen it defined as that broad a range, nor do I believe that is the current usage. Regardless of the etymology of the word I was using it to mean something larger scale, say 10^3 lines at a minimum. Read my not in that context.
Design is design. A program can have good or bad design at many levels of abstraction.
Again, we're parsing definitions. When most people speak of software design they are not speaking of the design of a 30 line routine, but rather of a module, subsystem or large unit. That was how I used the term, read my note in that context.
Regardless of that I do agree 100% with the statement you made, "You're right that it's important to look at the high-level ones, but many of the important clues about high-level design lie in how things are working on smaller scales." This is, as you say, critically important. It is also something not explicitely called out in XP.
As far as I can tell, any refactoring of big issues can be broken down into a series of tiny refactorings.
This is the first place that we really disagree. I don't think you can get a 20,000 foot view from ground level no matter how man square feet you've examined carefully. The high level view is important and, I think, mostly ignored in XP.
A bold assertion. Do you mean to say that you've been unable to do it? That it's utterly impossible for anybody to do it based on some mathematical proof you have? Or just that you can't currently see how it would work?
I have the same proof that the XP proponents have. The results of years of experience in trying different things.
You are right about one thing though, I shouldn't say "they don't scale". What I should say is that they don't scale as well as a more comprehensive approach.
I guess I see the XP practitioners as sharing a lot of philosophy with the phonics people. They both have a hammer and they both think it solves all problems. Just as comprehensive literacy teaching involved phonics, so to does comprehensive project management involve XP (and agile, waterfall, JAD, RAD, structured... the list goes on). Both camps are sometimes remise in seeing the shortcomings of their approaches too. Which is a shame, because a complete set of tools is a very valuable thing.
More importantly if you have a big up front design you are likely to be more likely to stick to it, even when you realize that real life is different from the assumptions that you based your design on.
My experience is that any project that would make the 'stick to it' design decision you mention above is going to fail regardless of what flavor of project management they choose. A management plan cannot make up for a team that makes poor decisions in the field.
If, however, you assume compitence of the team then I see no reason to believe that, just as XP refactors code and therefore design explicitely, a non-XP approach can refactor code and design explicitly.
That said, I believe that an explicit design is axiomatically better than an implicit design. If people know what the design is they are more likely to be able to work to it and contribute to fixing it. There is little to no oppourtunity to do this in XP.
Likely the same way the XP folks know that they occupy the correct position. I've worked on projects and seen what happens.
To a first approximation software development is a lore that is passed and not some kind of a hard core science. Look carefully at all these things and pick what works best.
I have found tons of problems by using use cases, uml diagrams, state diagrams or even flow charts if I go back further and solved problems *before* man weeks of time were spent XPing code into existence only to be refactored correctly the second time through.
If you've written 1000 lines of code before you refactor, you're waiting way too long. I do little refactorings every few lines, and bigger ones whenever things don't look right.
Then, arguably, this isn't refactoring but something simpler.
In any case, to leave terminology aside, my point is that design is a higher level thing that helps 100K lines look, feel and behave similarly. XP doesn't address this well.
If a boss is such a micromanager that he's telling you which lines of code to work on every 15 minutes, then it's time for a new job. The people I work for recognize that I'm a professional and trust me to tend to my business, especially given how willing I am to explain it to them.
It may well be that changing jobs isn't an option. But this comment is utterly orthogonal to what I was saying anyway.
See above, I wasn't referring to the small work units. I agree 100% that the XP ideas work really well on the time scale of a day or a week, but they don't scale to a project or a large team.
You missed one thing though: Test-first is design.
That may be what the XP folks say, but it's a half truth at best.
Test first, if it tests any design, only tests the interface design.
That isn't sufficient and it isn't something that 'falls out' of continually peeling the onion and designing interface after interface and test after test. Design is a higher level thing and it isn't considered carefully enough in XP.
All the practices are tried and true, based on experience long before Kent Beck was using the word "extreme" this way.
There are two things wrong with this statement.
1) The same script doesn't work in all contexts.
2) It isn't possible to objectively measure 'best' practices for software projects. So, one might claim that testing first and then anarchy works well. One might even claim that it works better than anarchy and test last. But it is difficult to claim that it works best.
"Design" in the pure waterfall sense -- do 100% of the requirements before doing any of the design, do 100% of the design before doing any of the coding -- doesn't scale up to large projects or rapid development.
Right. This is why it's been ten years since most mainstream development used this model. It doesn't scale well and wasn't what I was suggesting.
What I was suggesting was that design through coding isn't as effective as design through explicit design. Or, design then code, don't code then design.
XP breaks the design/coding/testing cycle into very small iterations, each one as big as one automated unit test case.
Right. And just as waterfall doesn't scale to large projects, neither does XP. The reason that waterfall doesn't scale is because people can't know everything up front and design based on that comprehensive set of knowledge. The reason XP doesn't scale is because it results in code that has no high level design and thus is very difficult to enhance and maintain. Ask the kids on mozilla about that one. It took them better than two years to get the open source project rolling in no small part because of this issue.
What none of the XP books say is that developing unit tests is a design activity, and the unit tests are design artifacts!
No, the tests are controls that verify a contract. The contract is the design. So, while you are partly correct (i.e. *some* design must take place before the test is written, and that test is derived from that design), it is the fact that this designing of software isn't explicitly called out until code is written that is very troubling for anything but the smallest applications.
I'll take that, any day, over a hundred pages of out-of-date UML diagrams.
And I'll take a well run project over an anarchistic herd any day. In particular, I'll take the source code and UML bindings that good design tools provide (e.g. Rose) in a heartbeat.
You're right, antiquated design artifacts is worse than useless. It can actually cause problems. But that doesn't mean we should throw the baby out with the bathwater.
The reason some XP projects are successful is because they actually have testing as part of the game plan. It is *shocking* to me, having been in the industry for better than a decade and pounding code for 20 years, the state of testing in corporate america. Just atrocious.
There are many labs that don't test at all, and a vast majority test poorly. I've worked in some fortune 500 labs that didn't test at all. Scary stuff. Nothing life threatening, but all of a sudden I wasn't so convinced that the reason my account was misconfigured was because *I* gave wrong data. Simply bug riddled. Those that do test often do so manually. Forgetting for a moment that humans are likely to take short-cuts and not bother to execute tests they perceive to be out of the scope of their recent change, they are failable. Of course they are, that's how the bugs got there in the first place.
So, the XP folks have the testing thing down. They test before the code is written, and their tests are automated.
Then they take leave of their senses. The claim that because they've successfully turned one idea on it's head (i.e. testing *first*) that they can turn others is ludicrous. Design first is still valuable guys. I've eliminated thousands of bugs simply by having the right design to begin with. Waiting until you've cobbled something together that passes the test and then hoping that your boss will allow you to refactor is a loser. If it weren't Scott Adams wouldn't be a millionare.
So, write your tests first. But do your design before you code, not after you've put together a thousand lines of crap.
Maybe the air force does make it difficult. I've certainly seen some pretty tight networks myself, but that doesn't mean that everything is. And the subject in question is actually kind of a fringe subject that one might believe to be missed in security sweeps and such.
Slashdot Mirror
Hey lover, you might want to check out a linguistic construct known as implication. The implication here is, of course, not that he's going to crush the knowledge out of his skull, but that he's giving up on utilizing it in his job.
you're right, we do have a poor sense of risks in the U.S. Starting with your examples.
Why wasn't this happening naturally?
For the same reason all the steps in XP that are explicitly called out weren't happening naturally I suppose.
is a pretty different thing than saying, "XP has a fundamental flaw."
I didn't say that XP has a fundemental flaw. I said, in fact, that the testing first thing was good. I implied that iteration was good. I believe in a large number of the XP constructs. In fact, off the top of my head I don't know what they have that I would argue is wrong.
However, I do think it is incomplete.
I'm glad you think it's perfect. More power to you and best of luck on your projects. I find it to be insufficient for large scale projects without some additional, explicit, steps to build a coehesive whole.
Second, because a "proper up-front design" is amazingly difficult to get right, takes a long time to get right, and, if you can reach that point iteratively anyway, doesn't add as much business value as delivering a couple of iterations worth of software in the same time period.
We're close to agreement here, but let me just belabor this one additional post.
I'm not arguing for up-front design. As you rightly point out, it is amazingly difficult to get right. Perhaps impossible even as your second point is equally well taken. Requirements change and therefore the design will also.
I'd just like to see the XP movement embrace medium and high level design as an instrinsic feature of the methodology rather than an implicit fallout of some of the work done.
You claim to be trying to acsend to the level of a "doctor" or "lawyer" yet you can't parse a paragraph sufficiently to understand my point despite the use of intentionally vague terms.
There are many kinds of engineers involved in construction my man.
i think that you massively underestimate the sacrifice and hard work and effort it takes to become a "real engineer".
You don't know me from Adam. But I see, like so many before you, you've found it much easier to assume ignorance in those that think differently from you.
I suggest that you might want to broaden your horizons and consider that sometimes, maybe often, the person who disagrees with you is as smart and well educated as you are and still finds a different conclusion.
The best part is, I don't even think differently from you. I agree that "real" engineers require a lot more training than most of the folks that call themselves engineers in software.
What special rituals do you want?
Architecture should be part of the process. XP describes a process without explicit steps for architecture.
And when you did XP, what architectural problems did your team have without those special rituals?
None. We added the rituals. Each iteration included 'tests' (in the form of human walk throughs) to ensure adherence to design and refactoring of the design itself. Just like the code, we iterated over the design.
While I agree with you that the big win is to have testing regardless of when it's written I have to say that I agree with the XP folks concerning when is the best time.
I've worked on dozens of projects and the only ones that were well tested were the ones with explicitly formed testing groups. The reason for this is simple. Developers know they need to test. Management knows that testing needs to be done. If the testing is not done first, however, it is far too easy to ship the product three months late than to high five everyone and say, "great job, now we just have to spend six months testing and we're golden". The market pressures are quite strong to ship something now instead of doing QA.
There is a secondary issue as well. Development of software it a constructive task. It is very difficult for a developer to spend a month or a year building something and then turn around and do an effective job of trying to destroy it. It is much easier to get into that frame of mind before you've spent hundreds of hours being constructive. The XP folks have this part strongly right.
What's more valuable to the customer after a month - 80% of the functionality in clean, testable code? Or 0% of the code but a big pile of Visio diagrams?
After a month, clearly they will perceive more value in having some code (I quibble with the 80% figure though. Any application that can get 80% of the code written in a month is aproachable using *any* methodology).
After a year or two though. The story changes when you look at the longer term. An application that is properly designed and controlled will have better maintanability than one that was continually refactored into a thousand discrete chunks.
OK, you feel you have found and solved problems before writing code. Fair enough. However, consider how much time you have spent on that non-coding stuff, though, and how much you could have accomplished if you had spent that time writing tests and code.
I write tests and code. I claim that if one adds serious high level design to the XP development cycle that the amount of code produced goes down and, more importantly, the quality of the code goes way up. Perhaps not as important to the people doing the initial development as being told that they can work without thinking and then go back and think about whether they could have done things better, but clearly of great importance to the folks paying for the application. They will be the ones who continue to pay for it during it's maintenance and enhancement phases.
The article didn't say that OCR was faster than speech, it said that speech was faster than transcibing it.
Come on mod's, read more carefully.
I think the XP folks would agree with you. Nobody is advocating that you don't do design, just that you allow your design to stay flexible in the face of changing requirements.
I know the XP folks would agree with me. I'm one of them in a sense and know many of them.
My objection is that the methodology doesn't explicitly call for it. Therefore, folks paying attention to these higher level issues aren't practicing XP, but something like XP++.
These things should be called out in the core methodology and it isn't.
Arguing is always more fun once you have some facts.
In fact, I've used XP on more than one project, including the one I'm working on now, and am friends with a prominent agile author who taught me about those methods when they were still nascent. So I think I have the facts down cold.
Despite my knowledge of the subject, I think that XP's generally direction is only half good and the lack of focus on higher level constructs is dangerous. If you want to claim that *you* are using higher level constructs, then fine. But you are doing something *in addition* to what XP suggests, which is exactly what I was saying should be done.
Let's say you are a construction engineer and designing a building.
Yes. Indeed, let's say that.
* A building lasts for 30-50 years easily. Software lasts, what, 3 or 4 years before there is a new release significantly improved to justify a new expenditure?
* Buildings require little to no engineering intervention in the intervening period. A typical software project is several orders of magnitude more complex than a typical building. They require constant maintenance.
* Buildings that need new features rarely depend on engineers. For the most part repartitioning of the cubes, or even moving a non-bearing wall, requires no engineering. Software gets new features regularly and requires engineers to get the job done.
So, while I'm a consultant and love it. To say that everyone need be is speculation about what the state of things might be, based on a completely untenable position. Software and building engineers aren't the same and never will be.
Refactoring is improving the design of existing code. Be it 10^1 or 10^6 lines, if you're changing the design without changing the functionality, it's refactoring.
I've never seen it defined as that broad a range, nor do I believe that is the current usage. Regardless of the etymology of the word I was using it to mean something larger scale, say 10^3 lines at a minimum. Read my not in that context.
Design is design. A program can have good or bad design at many levels of abstraction.
Again, we're parsing definitions. When most people speak of software design they are not speaking of the design of a 30 line routine, but rather of a module, subsystem or large unit. That was how I used the term, read my note in that context.
Regardless of that I do agree 100% with the statement you made, "You're right that it's important to look at the high-level ones, but many of the important clues about high-level design lie in how things are working on smaller scales." This is, as you say, critically important. It is also something not explicitely called out in XP.
As far as I can tell, any refactoring of big issues can be broken down into a series of tiny refactorings.
This is the first place that we really disagree. I don't think you can get a 20,000 foot view from ground level no matter how man square feet you've examined carefully. The high level view is important and, I think, mostly ignored in XP.
A bold assertion. Do you mean to say that you've been unable to do it? That it's utterly impossible for anybody to do it based on some mathematical proof you have? Or just that you can't currently see how it would work?
I have the same proof that the XP proponents have. The results of years of experience in trying different things.
You are right about one thing though, I shouldn't say "they don't scale". What I should say is that they don't scale as well as a more comprehensive approach.
I guess I see the XP practitioners as sharing a lot of philosophy with the phonics people. They both have a hammer and they both think it solves all problems. Just as comprehensive literacy teaching involved phonics, so to does comprehensive project management involve XP (and agile, waterfall, JAD, RAD, structured... the list goes on). Both camps are sometimes remise in seeing the shortcomings of their approaches too. Which is a shame, because a complete set of tools is a very valuable thing.
More importantly if you have a big up front design you are likely to be more likely to stick to it, even when you realize that real life is different from the assumptions that you based your design on.
My experience is that any project that would make the 'stick to it' design decision you mention above is going to fail regardless of what flavor of project management they choose. A management plan cannot make up for a team that makes poor decisions in the field.
If, however, you assume compitence of the team then I see no reason to believe that, just as XP refactors code and therefore design explicitely, a non-XP approach can refactor code and design explicitly.
That said, I believe that an explicit design is axiomatically better than an implicit design. If people know what the design is they are more likely to be able to work to it and contribute to fixing it. There is little to no oppourtunity to do this in XP.
Have you? How do you know that?
Likely the same way the XP folks know that they occupy the correct position. I've worked on projects and seen what happens.
To a first approximation software development is a lore that is passed and not some kind of a hard core science. Look carefully at all these things and pick what works best.
I have found tons of problems by using use cases, uml diagrams, state diagrams or even flow charts if I go back further and solved problems *before* man weeks of time were spent XPing code into existence only to be refactored correctly the second time through.
If you've written 1000 lines of code before you refactor, you're waiting way too long. I do little refactorings every few lines, and bigger ones whenever things don't look right.
Then, arguably, this isn't refactoring but something simpler.
In any case, to leave terminology aside, my point is that design is a higher level thing that helps 100K lines look, feel and behave similarly. XP doesn't address this well.
If a boss is such a micromanager that he's telling you which lines of code to work on every 15 minutes, then it's time for a new job. The people I work for recognize that I'm a professional and trust me to tend to my business, especially given how willing I am to explain it to them.
It may well be that changing jobs isn't an option. But this comment is utterly orthogonal to what I was saying anyway.
See above, I wasn't referring to the small work units. I agree 100% that the XP ideas work really well on the time scale of a day or a week, but they don't scale to a project or a large team.
You missed one thing though: Test-first is design.
That may be what the XP folks say, but it's a half truth at best.
Test first, if it tests any design, only tests the interface design.
That isn't sufficient and it isn't something that 'falls out' of continually peeling the onion and designing interface after interface and test after test. Design is a higher level thing and it isn't considered carefully enough in XP.
All the practices are tried and true, based on experience long before Kent Beck was using the word "extreme" this way. There are two things wrong with this statement. 1) The same script doesn't work in all contexts. 2) It isn't possible to objectively measure 'best' practices for software projects. So, one might claim that testing first and then anarchy works well. One might even claim that it works better than anarchy and test last. But it is difficult to claim that it works best. "Design" in the pure waterfall sense -- do 100% of the requirements before doing any of the design, do 100% of the design before doing any of the coding -- doesn't scale up to large projects or rapid development. Right. This is why it's been ten years since most mainstream development used this model. It doesn't scale well and wasn't what I was suggesting. What I was suggesting was that design through coding isn't as effective as design through explicit design. Or, design then code, don't code then design. XP breaks the design/coding/testing cycle into very small iterations, each one as big as one automated unit test case. Right. And just as waterfall doesn't scale to large projects, neither does XP. The reason that waterfall doesn't scale is because people can't know everything up front and design based on that comprehensive set of knowledge. The reason XP doesn't scale is because it results in code that has no high level design and thus is very difficult to enhance and maintain. Ask the kids on mozilla about that one. It took them better than two years to get the open source project rolling in no small part because of this issue. What none of the XP books say is that developing unit tests is a design activity, and the unit tests are design artifacts! No, the tests are controls that verify a contract. The contract is the design. So, while you are partly correct (i.e. *some* design must take place before the test is written, and that test is derived from that design), it is the fact that this designing of software isn't explicitly called out until code is written that is very troubling for anything but the smallest applications. I'll take that, any day, over a hundred pages of out-of-date UML diagrams. And I'll take a well run project over an anarchistic herd any day. In particular, I'll take the source code and UML bindings that good design tools provide (e.g. Rose) in a heartbeat. You're right, antiquated design artifacts is worse than useless. It can actually cause problems. But that doesn't mean we should throw the baby out with the bathwater.
The reason some XP projects are successful is because they actually have testing as part of the game plan. It is *shocking* to me, having been in the industry for better than a decade and pounding code for 20 years, the state of testing in corporate america. Just atrocious.
There are many labs that don't test at all, and a vast majority test poorly. I've worked in some fortune 500 labs that didn't test at all. Scary stuff. Nothing life threatening, but all of a sudden I wasn't so convinced that the reason my account was misconfigured was because *I* gave wrong data. Simply bug riddled. Those that do test often do so manually. Forgetting for a moment that humans are likely to take short-cuts and not bother to execute tests they perceive to be out of the scope of their recent change, they are failable. Of course they are, that's how the bugs got there in the first place.
So, the XP folks have the testing thing down. They test before the code is written, and their tests are automated.
Then they take leave of their senses. The claim that because they've successfully turned one idea on it's head (i.e. testing *first*) that they can turn others is ludicrous. Design first is still valuable guys. I've eliminated thousands of bugs simply by having the right design to begin with. Waiting until you've cobbled something together that passes the test and then hoping that your boss will allow you to refactor is a loser. If it weren't Scott Adams wouldn't be a millionare.
So, write your tests first. But do your design before you code, not after you've put together a thousand lines of crap.
Maybe the air force does make it difficult. I've certainly seen some pretty tight networks myself, but that doesn't mean that everything is. And the subject in question is actually kind of a fringe subject that one might believe to be missed in security sweeps and such.