David S. Read

I recently overheard a development leader talking with a team of programmers about the trade-off between the speed of developing working code and the effort required to improve the run-time performance of the code.  His opinion was that it was not worth any extra effort to gain a few hundred milliseconds here or there.  I found myself wanting to debate the position but it was not the right venue.

In my opinion a developer should not write inefficient code just because it is easier.  However, a developer must not tune code without evidence that the tuning effort will make a meaningful improvement to the overall efficiency of the application.  Guessing at where the hotspots are in an application usually leads to a lot of wasted effort.

When I talk about designing and writing efficient code I am really stressing the process of thinking about the macro-level algorithm that is being used.  Considering efficiency (e.g. big-O) and spending some time looking for options that would represent a big-O step change is where design and development performance effort belongs.

For instance, during initial design or coding, it is worth finding an O(log n) alternative to an O(n) solution.  However, spending time searching for a slight improvement in an O(n) algorithm that is still O(n) is likely a waste of time.

Preemptive tuning is a guessing game; we are guessing how a compiler will optimize our code, when a processor will fetch and cache our executable and where the actual hotspots will be.  Unfortunately our guesses are usually wrong. Perhaps the development team lead was really talking about this situation.

The tuning circumstances change once we have an application that can be tested.  The question becomes how far do we go to address performance hotspots?  In other words, how fast is fast enough?  For me the balance being sought is application delivery time versus user productivity and the benefits of tuning can be valuable. (more…)

The annual Business Rules Forum is right around the corner… starting on November 1.  For the third year Blue Slate has been invited to share our insights with the attendees.  I will have an opportunity to speak about the importance of viewing all data through the lens of  a company’s business rules.  The title of my talk is, ‘Business Rules in the Integration Tier: The System of Record‘.  It is scheduled for Wednesday, November 4 at 2pm (moved from 3:05pm).

I am excited and honored to be given another opportunity to speak at the preeminent conference for business rules.  Beyond sharing my thoughts I am looking forward to learning from the many practitioners that will be discussing their insights as well.  The variety of experts, topics and industries creates a valuable opportunity for anyone looking to begin or expand the use of rule-based approaches within his or her business.

In addition to the sessions, I highly recommend attending one or more of the “Fun Labs”.  They provide an opportunity to use the vendors’ products and get your questions answered.  The chance to explore these tools and see the entire process of creating, editing and running rules is powerful.

Read on for details about how this conference provides many great opportunities for learning about the techniques, tools and products that support effective application of rule-centric approaches.

About the Business Rules Forum Conference

**The only conference world-wide with all the vendors under one roof at one time!**

Have a look at this year’s program. Find out what the excitement is all about!

Download a copy of our new Conference Brochure featuring highlights of this year’s unparalleled event.

(more…)

You’ve probably heard an expression similar to, “If builders built buildings the way programmers wrote programs, the first woodpecker that came along would destroy civilization.” At face value it is amusing and seems in some ways prophetic.

After all most computer users have experienced countless software failures that led to lost data, reduced productivity and basic frustration. If our buildings’ infrastructures failed as often we wouldn’t dare enter them. The earlier quote makes a not-so-subtle statement that programmers do not do as good a job when constructing software as their building builder brethren do when building buildings.

However, the premise of the quote, and others like it, is fatally flawed. Statements of this nature assume that building a physical structure is like creating software. I disagree strongly. In fact I think the two are as similar as bridge construction and music composition, i.e. not very.

In this category’s posts I intend to flesh out my thoughts on the process of software creation, or composition as I like to call it.