a view of the Marsh

...: Chatter by Year

2016

October

2014

March

February

2013

September

July

June

March

February

January

2012

December

November

October

September

August

July

June

May

April

March

February

January

2011

November

October

July

June

May

April

March

February

January

2010

December

November

October

September

August

July

June

May

April

March

February

January

2009

December

November

October

September

August

July

June

May

April

March

February

January

2008

December

November

October

September

August

...: Chatter by Keyword

ASP.NET

Browsers

Business

Cascading Styles (CSS)

Charity Work

Community

Definitions

Design

Education

Ethics

Firefox

First Post

Hockey

I.T. Events

Internet Explorer

Junk mailer/poster

Life

Microsoft

MS Access

Music

Other sports

Printers

Programming

sci-fi

Software

Speaking/Presentations

SQL

Survey

Teaching

The Marsh

Tips & Tricks

Tools of Trade

U.S. Events

Visual Basic (VB.NET)

Web Design

World Events

...: Marsh Chatter

Choices… A Recurring Series: StringBuilder…

String concatenation (e.g. a fancy word for joining strings) is one of the most frequent processes a program performs. Unfortunately, done wrong it can be the major cause of a slow running program – especially when the concatenation is buried in a loop.

Little Background? What is this Immutable thing?

Don’t you just love terminology? Oh so necessary, but the hard part of learning. In short, the common dictionary definition for immutable is something that doesn’t change.

In our industry, strings are known to be immutable; that is, if you change a string, your program actually creates a new one and then deletes the original. There is a cost in time and memory for this process. On top of that – strings are one of the most memory intensive data types we have. Hence, this type of string operation tends to be slow.

Help is in the Framework

Within the .NET Framework is the StringBuilder object which enables fast string handling. Let me repeat that... fast string handling. If you've used it - you know! If you haven't, it is time to learn!

Testing, Examples, and Results on the web

Each of these articles offer great detail, suggestions, and results. There is no reason for you or I to duplicate their testing methods - unless of course you are just looking for a challenge.

Conclusions

Once you see the results in your own code, you might as a general rule, for consistency - argue for using the StringBuilder objects for any string concatenation. Of course, there are always caveats to any "rule"; such as, the slight cost in memory or processor cycles in setting up the object prior to usage.

If you're tacking 2 or 3 strings together, you probably aren't going to save much time, however, if your code will concatenate more or a variable number of strings together, you will probably want to use a StringBuilder to perform that work. This is especially true if the concat will occur within a loop.

Future - Choices… A Recurring Series:

While string concatenation is slow, your code probably has bigger optimization targets. One of the most common is accessing data in files (e.g. hard drive speed issue), or accessing data in files across a network (e.g. significant bandwidth issues).

We will look at potential solutions when using data files (e.g. file-based databases) in your programs. Specifically, this series will relate to web applications. See you then.

Go 1/2 way, then go 1/2 way, then go 1/2 way...

Or "When is it... done or good enough or complete"?

How do you know when to stop working on a project? That sure is a tough question! Do you realize that many book publishers have to stop authors from continually rewriting parts of a book? Well they do. Just like a programmer revamping one more method, a book author is always "tweaking" just one more word or paragraph. Once published, you spot many more items that you wanted to change.

When is a program done? Well that is a decision you and your client will have to make. In nearly all cases you will find the decision revolves around 2 things - usually referred to as...

Most 'bang for the buck'

Or more appropriately - it's a features vs. cost decision.

Let's break this down a bit...

After the initial design stage and the heads-down programming process begins, I tend to "see" 3 separate functional stages or tiers. The lowest tier: the 'rough-in' stage, the mid-tier: the 'closing in' stage, and the upper tier: the 'finishing' stage.

For anyone who has watched a few shows of This Old House or various HGTV shows - you will find my use of house building metaphors to be a close fit. If you don't watch these shows or have never owned or built a house... well just play along, you'll pick it up.

Low Tier - rough-in stage

The lowest tier is where there isn't enough of anything for the client to see, much less do anything. Think of this as staking out the footprint, laying the basic foundation parts, and pouring the concrete. The stairs are really a ladder, no floors, walls, or roof. Hard hats are required and contractors usually don't want the customer on the job-site because of the dangers.

Now contrast this to a program. You're developing the database, the code to connect to the database, the basic form structure, there is the high probability for parts not to work, and the slightest change causes a crash. As with the house job-site, this stage in the project can be upsetting to the client. They "don't get the picture" yet, the errors scare them, and they wonder why the demo worked, but now the product doesn't. Clients hovering around do not help at this stage of development.

Mid-Tier - closing in stage

The mid-tier is where your client can actually begin to see the product. In the house build - this is where the framing goes up, electrical, plumbing, and heating & cooling is installed. The end of this stage sees the drywall go up and the rooms take shape. Customers can really see "the house".

For the program, this stage seems to be the longest, but it is also where the product really takes shape. Data can be entered, buttons pressed, functionally the program begins to work and could begin to provide some productivity gains.

Clients can now see the whole picture and thus they begin to make suggestions - call them 'what-ifs' or 'how about this' or 'can this be done'. We call this scope creep. In the building trades... it's a change-order. Either way it means extra work and not always easy work because of the redesign and structural changes necessary to weave in the new parts.

Upper Tier - finishing stage

Keeping with the house building metaphor, this is the stage where the moldings are put up, the final paint work, staining, wallpaper, and more are completed. At this stage, the customer is getting anxious. They see the house, they can walk through it, and they wonder why they can't move in yet. "It doesn't seem like a lot of work, to them". But the final details - precision cutting/fitting of moldings, flooring, drying time between applications, etc. all take time.

To the developer, optimization thoughts creep in. Change this code to make it faster or more lean in code lines. Refactoring benefits future development, but again, you must weigh the time value in this "first version". Make the change that saves processing time, make the change that creates a more intuitive process, but don't make the change "just because" - be sure there is value in a change.

In the program world, I consider this the "high-cost, high-effort" tier. This means that it will take a long time and cost a lot of money to make something 100%. As if any program can ever be 100% - some feel it can, yet they immediately suggest one more feature - thereby making it less than 100%.

This stage in programming can eat up a lot of time, without equivalent monetary return. It is this stage where most consulting contracts break down. Errors are reported, but turn out to be function or design changes - not true errors. Essentially the design & planning was not deep enough to ensure everyone would be satisfied. These what-ifs have to be turned into version 2 or 3 features.

1/2 step, 1/2 step, more

You would think "good enough/complete" would be understood by all, as it is prevalent in all industries where "building" takes place. But the "when will it be done, foot tapping" always occurs during that third stage, right after the scope changes have been submitted.

Consider setting up the project to have shorter goal "steps". Get to an early productivity step and roll the product out. Enable the client to use the product while you weave in the next puzzle piece. Each stage you increase the client's productivity, while enabling yourself to work on the project a piece at a time. Business wise - this enables you to start and maintain the cash flow. For the client, if they want to stop the project, they can - while still having a product that works and provides some level of productivity.

All projects, be they: applications, programs, or buildings - reach a "good enough" stage - for that time, knowledgebase, and conditions. There will always be a new room to add, paint to change, menu item and form, code that can be tweaked - understand that at the beginning and your development life will be much easier for you.

Thoughts... Fertilizer

Has the economy got you thinking of a job/career change?

Are you worried about your current position?

Do you think that the grass is greener on the other side of the fence?

Try fertilizing your side first! You might find that your opportunities grow right where you are and then you don't have to "take a chance, elsewhere".