Processing, week 3
It’s been a week and a half since my Processing, week 2 post and I’m still not done with chapter four, “Time Series.” Oh, well.
I’ve been noticing that my Processing programs use a lot of CPU — about 35% on my dual-core, 2 GHz machine. And that’s for a program which just displays static data, like the one below. Read more
Processing, week 2
Today marks the second week I have been learning Processing, a Java-based language for “program[ming] images, animation, and interactions.” In other words, I want to learn how to make useful, pretty graphics. 
Over the past year I had seen Processing mentioned here-and-there in various articles, but what piqued my interest was a visualization of US zipcodes. Check it out; it’s awesome.
My guide, at least for now, is Visualizing Data by Ben Fry. I just completed reading the third chapter and thought I’d share an example program. Read more
Eckel: six hiring points
Following Java Posse Roundup 2008, Bruce Eckel wrote an excellent article outlining six things that you should test for when hiring someone. It contains the collective wisdom of the conference attendees, as articulated by Bruce, which I could not hope to improve upon.
The original points are numbered, one through six, but are not listed in any particular order. Were I to give them an order based on importance, they would be arranged as follows.
- Are you toxic?
- Can you learn? Can you solve problems?
- Critical thinking. Can you change?
- Technical knowledge.
Ok, I cheated; it’s hard to put them in an absolute order. All are important and relate to each other in some manner. All software developers — and managers thereof — should read the original!
Facts about software engineering
Robert L. Glass, in 2001, authored a collection of facts about software engineering titled Frequently Forgotten Fundamental Facts about Software Engineering. Glass wrote:
I don’t expect you to agree with all these facts; some of them might even upset you. Great! Then we can begin a dialog about which facts really are facts and which are merely figments of my vivid loyal opposition imagination!
In that spirit, I have selected one each of my favorite requirement and estimation facts.
RD2. When a project moves from requirements to design, the solution process’s complexity causes an explosion of “derived requirements.” The list of requirements for the design phase is often 50 times longer than the list of original requirements.
Indeed, suddenly a large body of previously-unknown work is materialized, complexity increases again, and the schedule doesn’t adjust (see ES2). The knee-jerk reaction, of course, is to spend hour-after-hour and day-after-day coming up with an exhaustive list of requirements. The process can be infinitely long (see analysis paralysis) and may only reach its end by artificial means. This problem alone may be one of the strongest arguments against waterfall-style development.
ES2. Most software estimates are performed at the beginning of the life cycle. This makes sense until we realize that this occurs before the requirements phase and thus before the problem is understood. Estimation therefore usually occurs at the wrong time.
Another good argument against waterfall. The risk inherent in this nearly inverse ordering is significantly reduced when software is produced in a more agile fashion. That is to say, analyzing requirements and producing estimates iteratively allows the risk to be mitigated incrementally.
See how we're connected.