Principles of Uncertainty

Uncertainty the only certainty in software development projects

I was conversing with some colleagues today and the subject of 'high level' estimates came up. We were snidely commenting (as is our prerogative) on the tendency of our superiors to ask for these and our discomfort with providing them.

Programmers have an intense dislike of getting things wrong. It's kind of paralyzing because we never want to discuss anything in depth that we're not 100% certain of.

It's comical to watch a smart developer give a high level time or complexity estimate to management. He'll be aloof and careful not to say anything incriminating. Probably because it feels like an interrogation. Usually his interrogators will press for something concrete to write down on a piece of paper that can be used in planning, but it's not easy to get this from the developer.

I think the problem is that the kind of people that like software development and choose it as a career are naturally petrified of being wrong. This fear is compounded by the belief that for any problem there may be a number of ways to solve it, but we want to find the perfect one.

We also have a distrust for 'high level' anything and prefer not to be part of that whole deal. We'd much sooner spend weeks researching and analyzing the problem until we understand every detail, then deliver the answer...

Be ready in a couple days.

How Many Apartments for a UI Thread

With WPF, drawing and binding can be time consuming for large UI projects. If updating the UI takes a while, you need a second UI thread to display progress, but if you try to start a progress window from a worker thread, the framework will complain that the thread has too many apartments (I'm paraphrasing of course)!

The trick is to initialize the thread STA, start the thread message pump and use a dispatcher to send code to the thread for execution.

Use the following code to roll a progress indicator. Not shown is the ProgressDialog class which for me is a XAML window that exposes a progress bar (named bar) and a label (named label)

class ProgressIndicator
    {
        Thread t;
        ProgressDialog progdialog;
        bool running = false;
        public void Start()
        {        
            t = new Thread(ThreadFunc);
            t.SetApartmentState(ApartmentState.STA); // set the thread to STA
            t.Start();
            while (!running) ; // block until the thread is ready to accept updates
        }

        public void UpdateProgress(double Progress, String label)
        {
            progdialog.Dispatcher.BeginInvoke(
                (System.Windows.Forms.MethodInvoker)delegate() { progdialog.bar.Value = Progress; progdialog.label.Content = label; }
                                        );
        }

        public void Stop()
        {
            try
            {
                progdialog.Dispatcher.BeginInvoke(
                    (System.Windows.Forms.MethodInvoker)delegate() { progdialog.Close(); }
                                            );
                t.Abort();
                t.Join();
            }
            catch (Exception)
            {
            }
            finally
            {
                t = null;
            }
        }

        protected void ThreadFunc()
        {
            progdialog = new ProgressDialog();
            progdialog.Show();
            progdialog.Closed += (sender2, e2) =>
                progdialog.Dispatcher.InvokeShutdown();  // if main window closes...

            progdialog.bar.Maximum = 1;   // I always like dealing with 0 -> 1 progress
            running = true;
            System.Windows.Threading.Dispatcher.Run();  // start the message pump
            
        }
    }

Copy and paste the code and implement the ProgressDialog class with a progress bar named bar and a label named label and this should let you start and update a progress bar in a second UI thread.

Domain upgrade and switch to blogger

Well, I bought the robertmcintosh.ca domain and moved the blog to hosted blogger rather than self hosted wordpress.
I use wordpress for waterloobikes.ca blog, but overall it's not impressive. They insert ads where Google leaves that up to the blogger. Domain pointing is free at blogger, but paid at Wordpress.
Best news is I've got the domain. It's a huge move for my image as a contractor. No more org tld's and I can even use an email address for free from the registrar.
I think things are moving along...

Prepare to Program Series I

The first key to writing guud software is getting a proper sit going. You have to be comfortable if you're sitting at the terminal for 12-18 hours per day doing what you love. Some days I want to mount my keyboard and monitors above my bed so I can get a real guud sit going.


I don't because I think that might be crossing a line into domestic impropriety.

I love to write software especially when creating something new (fixing bugs is a regrettable but necessary exercise). But nothing gets in the way like an uncomfortable work zone. Take your home computer workstation (if you have one). Could you sit there all day?

I feel highly misunderstood when I get into a real good comfortable spot that feels just right. I'm often nearly laying down in my chair. I have my head back, looking down my nose at the monitors. Were it not for my fingers moving, you'd think I was sleeping with my eyes open.

Inevitably, not recognizing that I am in fact in the programmers zone, interrupts with - "are we keeping you awake". I like to respond - "you are now".

Continuous Integration

When I was a developer at a small company that sold products which happened to include software we did a lot of things different. The main reason for this is that software was a part of what we were producing, but not the main part. Elevators, electric dune buggies, CNC machines all have significant non-software development components.

The delta's show in how much attention is paid to the processes surrounding the development of each component. For example, one of our favourite ways to test software that was developed for CNC machines was to load the software onto a CNC machine and press buttons and use any new software that was implemented. The goal was to test the software for correctness and bugs. To us, this was a reasonable facsimile to a production environment.

I now work on a large team of software developers who are professionals at producing software. It's very time consuming or even impossible to test new software IRL because the production environment is not easily simulated. Continuous integration and unit testing allows me to develop software and be reasonably secure how it will perform in the field without having to 'press the buttons'.

Of course, running unit tests is not foreign to the previous shops in which I've practiced my craft. The problem with unit tests was almost always the same. The tests would be run during the development of a feature, then never used again. Instead, they might never see the inside of a version control system. They would be lost on next computer upgrade. It was hard to justify so much time writing unit tests that would only be used to aid the developer implement.

With Continuous Integration, it's different. The build and integrate process is continuous (imagine that). Each build is done on a dedicated system. All unit tests are automatically run and if everything goes ok, the build is deployed to testing fixtures which run continuously.

This process makes it more difficult for new code to break old code (as long as it's adequately tested). I wish I knew that before I wasted all those hours tracking down bugs by trying to manually set them up over and over with the user interface.

Solving Problems

There's nothing like the sense of accomplishment you get from solving a problem. When you're new, it's frequent that you get to solve problems. Well, maybe that's inaccurate everything you touch is a problem because you've never seen it before, you haven't learned enough yet.

Scratch, scratch, scratch your head sometimes for hours or days. Then, you get it. You've learned just enough to solve the problem and you feel accomplishment because:

1. You solved a problem
2. You learned something

Makes for a good day.

Tooting Your Horn

Software Developers are notorious introverts. There are very few who love to tell the world how good they really are at things. I'm improving, but it's not my default demeanor. It makes me uncomfortable to take credit, or to announce when I do something well. Sidebar - I'm very practiced at taking blame. I do it pretty smoothly.

People making hiring decisions, handing out assignments and deciding who's next to run the group are usually looking for great people to do those jobs. The greater the better. They are going to take the greatest one they can get (most of the time).

If they have to interrogate you to find out your level of greatness, they might take a pass. After all, the next guy in line is making it easy to find out how great he is. You don't want to bludgeon anyone over the head with self-serving arrogance, but it shouldn't be a secret either.

I try to make it part of my day to do something great, something unexpected, better than expected. The next step I have to master is making sure the right people find out about it.