The venerable master Qc Na was walking with his student, Anton. Hoping to prompt the master into a discussion, Anton said “Master, I have heard that objects are a very good thing - is this true?” Qc Na looked pityingly at his student and replied, “Foolish pupil - objects are merely a poor man’s closures.”
Chastised, Anton took his leave from his master and returned to his cell, intent on studying closures. He carefully read the entire “Lambda: The Ultimate…” series of papers and its cousins, and implemented a small Scheme interpreter with a closure-based object system. He learned much, and looked forward to informing his master of his progress.
On his next walk with Qc Na, Anton attempted to impress his master by saying “Master, I have diligently studied the matter, and now understand that objects are truly a poor man’s closures.” Qc Na responded by hitting Anton with his stick, saying “When will you learn? Closures are a poor man’s object." At that moment, Anton became enlightened.
A programmer that knows one language will think it’s perfect and defend it fanatically.
One who knows more than one language hates them all.
(…) no matter how much effort you put into thinking you’ll very probably discover things your forethoughts missed. While coding ahead, once you start to code, you’ll have better thoughts.
(…) thinking without coding involves inadequate negative feedback. There are no reliable tests you can run that can tell you if your thinking is staying close to reality. Without that negative feedback, it’s hard to know if you’re thoughts are practical (…)
So, should you think ahead? Of course; but don’t give those forethoughts special status or special trust.
When I say “Agile” I mean what I think Agile “can be”. This part can become very complicated, so let me outline some things that I mean when I say “Agile”.
- Not a defined process, but a way for people to discover an appropriate process for them. (Thanks, Alistair Cockburn.)
- A toolbox of helpful techniques which I sometimes use as a starting point when we don’t know where else to start. (Thanks, Kent Beck, Ron Jeffries, and other early XP authors.)
- The basic assumption that when we don’t know what else to improve, then we try to earn more value sooner. (Thanks, Mary and Tom Poppendieck.)
- The basic assumption that learning is the bottleneck in delivering products. (Thanks, Taiichi Ohno and Eli Goldratt, among others.)
- The basic assumption that what’s good for people will be good for projects, products, and companies. (Thanks, Jerry Weinberg, Tom DeMarco, Tim Lister, Brian Marick, and so many others.)
Q: What is the most often-overlooked risk in software engineering?
A: Incompetent programmers. There are estimates that the number of programmers needed in the U.S. exceeds 200,000. This is entirely misleading. It is not a quantity problem; we have a quality problem. One bad programmer can easily create two new jobs a year. Hiring more bad programmers will just increase our perceived need for them. If we had more good programmers, and could easily identify them, we would need fewer, not more.