Monday, January 14, 2019

Artful Digression

This blog is focused on the art and science of software development, but I don't want to imply that the contents herein represent a full picture of a programmers life. A great deal of outside experience ultimately influences your qualities as a software developer. This varies by person and personality, but for me the key outside activities for success are reading and walking.

You should make an effort to discover various trade and technical magazines, even publications related to your specialty that you wouldn't otherwise consider visiting. You should make an effort to research the state-of-the-art in the business use of computers as well as strategic advancements happening in your industry and related industries. I also recommend a broad general reading background of a variety of magazines: you never know when a strange juxtaposition of unrelated ideas will lead to a new breakthrough.

I can't overstate the value of walking. Not only does it clear your head of the clutter and confusions of political interests, the rhythm of your legs and the change of natural scenery will make you more aware of the proper balances in design. It will help you create a more naturalistic and organic path for your growth. Walk. Read.

Friday, December 14, 2018

The Art of the Job

Every couple of years my mom asks "What exactly do you do?"

Exactly? Well you see she only knows about computers from her laptop and the internet. So what does the job of being a software developer actually consist of? The easiest way to describe it (the work-work part of the job that is, aside from the social or sociological part of the job) is in terms of all of the steps involved in battling through a software project. This is the so-called SDLC, the software development lifecycle:

Research current and near-future relevant technology
Interview or focus sessions with clients
Develop implementation alternatives
Research vendors
Review alternatives with management
Develop a project planDevelop functional specifications
Design data flow and data structures
Develop design specifications
Design draft of interface
Various programming tasks
Unit test programming
Software corrections from unit testing
System and stress testing Software
Corrections from system and stress testing
Alpha testing
Software corrections from alpha testing
Regression testing
Software corrections from regression testing
Technical documentation
Develop implementation plan
Develop training materials
Develop online help
Beta or parallel production testing
Post implementation corrections
Production Support

Well yeah, it's a lot of stuff, and it's what makes the job always interesting and challenging.

Friday, October 12, 2018

Artistic Multitasking

Multithreading is a wonderful tool but you need to use it very carefully. First don't use it recklessly, as there are specific instances where it is of most benefit (see this post for examples). If you are not in a "cloud" environment that scales-out to add additional CPUs as required, then I have four tips to help you along your way.

1. Tip 1 is to be sure to assign the Name property an each thread you start. This is really the only way to tell which thread caused exceptions and is the only clue when you're debugging of how you got here. Use a name relevant to the instigator method and the serial count of that particular thread.

2. Think in terms of threads working on an instance of an object. This helps keep multiple threads from stepping on each others memory space. Put all the values for input into properties of your new object, create a method in that object that performs the "heavy lifting" and deep calculations, and then execute that method through the thread.Start (placing return values back into a property). As an added tip I like to build an array-list of all the objects I have actively submitted to threads; when the thread terminates I can pop its values out of the array and then null out its instance.

3. If you anticipate that you may ever need the capability to abort the thread you are starting (for example if the user cancels the operation) it is far far better to make provisions for this within the thread, in the method you are executing, rather than using thread.Abort. I usually create a boolean property in my main class called panicStop. All threads check this value within each iteration of a for-loop, and bail out appropriately.

4. Manage the quantity of threads you allow to run simultaneously. Beyond a certain threshold (depending on the number of CPUs on your box and other factors) firing more threads doesn't aid performance much. So manage it.

Multithreading works great as long as you remember to use it for appropriate tasks, and pass each thread a new object to work on. Remember that you are flowing parallel, but in separate "streams", so as to avoid conflating the instance of each object.