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.

Update: thanks to a helpful suggestion, I was able to decrease CPU usage significantly. To find out how, read the comments section.

Oops, your browser does not have a Java Plug-in. Get the latest Java Plug-in here. Or, if you have Java but can’t use the Plug-in, feel free to download the program as an executable jar.

This program, from Visualizing Data, plots some US beverage consumption stats over a period of time. Clicking anywhere within the app switches the subject beverage.

Unless I’m missing something, the excessive CPU usage is due to constant re-draw. The book puts all drawing code within the draw() method which is called repeatedly, up to 60 times per second (by default). Setting the frameRate() to 30 fps improves the matter, but only marginally.

As I was putting in the reference link for draw(), I noticed the documentation indicates its continuous execution can be disabled with noLoop(). That’s great, but has the side effect of disabling key or mouse events.

For now I’m willing to overlook this CPU usage “problem” but I hope the book addresses it soon.

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.

The above Processing program plots data on a US map. The data are random numbers, associated with each state, which are displayed as colored circles of varying sizes. Colors are based on sign; size based on magnitude. Moving the mouse cursor over a circle displays the state name and the random value.

Obviously, this is a very simple visualization but it’s not hard to see the potential for powerful visualizations. I’m already coming up with other data to visualize with this… such as displaying the difference between the current and average daily temperature for a state.

Oh, before you get to comfortable with that static graphic, click anywhere on the map. Neat, huh? A new random number is generated and the graphic is animated from the old value.

Over the course of this coming week I will read the fourth chapter, “Time Series,” about displaying data which changes over time. I can’t wait to see what program the book will have me work on.

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.

1. Are you toxic?
2. Can you learn?  Can you solve problems?
3. Critical thinking.  Can you change?
4. 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!

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.