It's worth remembering in this shiny nuclear-powered Agile era that Tom Gilb wrote Principles of Software Engineering Management over 900 years ago. Or thereabouts. What's new is us young upstarts hearing about it for the first time and thinking we've discovered something new. And I can't help feeling that's partly because we're not exposed to folk who've been around long enough to remember. Teams burn a lot of time relearning the same lessons people were learning decades ago.
Once, a farmer interviewed a young man for a job as a farm hand. One thing the young man said particularly puzzled the farmer, “I can sleep when the wind blows.” The farmer didn’t know what this meant, but the young man seemed competent and knowledgeable and so he was hired.
A few months later the farmer was awakened in the middle of the night by a thunderous wind storm. Panicked, he raced to the cot where he found the farm hand fast asleep. Shaking him roughly awake, he demanded, “We have to bring in the animals!”
“They are already in.”
“We need to fasten the windows.”
“They are already fastened.”
“We need to tarp the hay.”
“It’s done.”
After going down his list of worries and being reassured that they were already taken care of, the farmer finally realized the meaning of the young man’s puzzling statement. By taking care to finish every job and leave the farm safe every night, the farm hand could sleep when the wind blew.
Planned reuse has been widely discredited in software development, especially after the Big Push For Reuse that we saw in the 90's.Writing code on the basis that it may be applicable in multiple future scenarios is speculation, and speculative generality is considered a code smell. The danger is that when the future comes, the reusable generalisation we planned turns out to be not quite what is actually needed, or doesn't quite fit all the scenarios, or - more usually - that the future eventuality never comes up.
Software development is hard enough when we have to write code that satisfies today's requirements. Adding in a whole bunch of "what if?" code makes it even harder, we have found.
My recommendation is to introduce eight-ball into school curricula, but in a specific way. Each kid would be required to keep a log of hours spent practicing on his own time, and there would be no minimum requirement. Some kids could practice zero hours if they had no interest or access to a pool table. At the end of the school year, the entire class would compete in a tournament, and they would compare their results with how many hours they spent practicing. I think that would make real the connection between practice and results, in a way that regular schoolwork and sports do not. That would teach them that winning happens before the game starts
Boyd decided that the primary determinant to winning dogfights was not observing, orienting, planning, or acting better. The primary determinant to winning dogfights was observing, orienting, planning, and acting faster. In other words, how quickly one could iterate. Speed of iteration, Boyd suggested, beats quality of iteration.
The next question Boyd asked is this: why would the F-86 iterate faster? The reason, he concluded, was something that nobody had thought was particularly important. It was the fact that the F-86 had a hydraulic flight stick whereas the MiG-15 had a manual flight stick.
Without hydraulics, it took slightly more physical energy to move the MiG-15 flight stick than it did the F-86 flight stick. Even though the MiG-15 would turn faster (or climb higher) once the stick was moved, the amount of energy it took to move the stick was slightly greater for the MiG-15 pilot.
With each iteration, the MiG-15 pilot grew a little more fatigued than the F-86 pilot. And as he gets more fatigued, it took just a little bit longer to complete his OOPA loop. The MiG-15 pilot didn’t lose because he got outfought. He lost because he got out-OOPAed.
I’ll state Boyd’s discovery as Boyd’s Law of Iteration: In implementing complex systems, it is better to act quickly than perfectly.
From Simple Architectures for Complex Enterprises (PRO-best Practices) (Best Practices (Microsoft))
I stumbled across this book in the local Barnes and Noble and opened it to a random page. This story. Interesting...
Over the years I have come to describe Test Driven Development in terms of three simple rules. They are:
- You are not allowed to write any production code unless it is to make a failing unit test pass.
- You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are failures.
- You are not allowed to write any more production code than is sufficient to pass the one failing unit test.
You must begin by writing a unit test for the functionality that you intend to write. But by rule 2, you can't write very much of that unit test. As soon as the unit test code fails to compile, or fails an assertion, you must stop and write production code. But by rule 3 you can only write the production code that makes the test compile or pass, and no more.
Ellison says he has already stopped the carnage at Sun, less than four months after the sale closed in January. "Their management made some very bad decisions that damaged their business and allowed us to buy them for a bargain price," he told Reuters. He added that he expects profit from Sun's operations to boost Oracle's earnings in the current quarter, which ends May 31.
The integration has proceeded swiftly, says Ellison, because a protracted antitrust review in Europe gave Oracle time to draw up an exhaustive plan for resuscitating Sun. In typical Ellison fashion, he took a hands-on approach to the integration, choosing to meet directly with technical managers at Sun as often as four days a week to diagnose its problems, rather than delegating the work to underlings.
There are no super programming languages, only super programmers. And they tend to be super jerks. I should know – I used to be one. What would really make a programming language be super powered is the ability to be used by normal people.
Please click through to read the entire post... It's worth the read.
“There are a whole other group of folks who play this game,” Mr. Tabb said. “They put low limit orders into the market for this exact purpose — for when the markets go into free fall.”
...Unfortunately for those investors, the exchanges have rules in place to cancel or rescind any trades that are associated with erroneous or unusual trading activity.
“If there is an order that gets printed and it is so far away from the market that it was clearly wrong, the exchanges have the right to break it and, in fact, they do it fairly often,” Mr. Tabb said. “It just doesn’t happen with this magnitude.”
On Friday, the Nasdaq market said it would cancel all trades that had occurred in the 20-minute period between 2:40 p.m. and 3 p.m. on Thursday that were 60 percent higher or lower than the last trade at 2:40. “This decision,” the exchange noted on its Web site, “cannot be appealed.”
