Open the Terminal application on a Mac and what do you see? A noble and worthy Unix “shell”, a program that geeks use to interact with the OS. Terminal uses the bash shell (for Bourne Again Shell. Created by Brian Fox, bash is based on the sh shell, which was invented by Stephen Bourne. Unix mavens love their word-play acronyms).

And now we have the Apple iOS, an OS X derivative that uses bits from the same kernel.

I believe part of the problem is a matter of confusing passion with lack of objectivity. Bobby Fischer - one the greatest world champions ever - was insanely passionate about chess. However, he was very objective about evaluating his position while playing. As a matter of fact, objectivity was one of his greatest virtues as a chess player.

Various execs fail to appreciate this distinction when they encounter strong passion. They don't quite get that one can be very passionate about a profession without affecting his/her objectivity with respect to the task to be carried out. Programming is a domain where this kind of failure takes place fairly frequently.

Israel

Posted by: israel Gat | December 27, 2009 at 02:57 PM

I think technical people, and engineers in particular, will always have good job prospects. But what if you don't have the aptitude or personality to follow a technical path? How do you prepare for the future?

I'd like to see a college major focusing on the various skills of human persuasion. That's the sort of skillset that the marketplace will always value and the Internet is unlikely to replace.

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

Best explanation with illustrations that I've come across....

Over the years I have come to describe Test Driven Development in terms of three simple rules. They are:

1. You are not allowed to write any production code unless it is to make a failing unit test pass.
2. You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are failures.
3. 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.