...: 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.
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.
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".