Random sometimes, not random other times

May 19, 2006 at 11:43 am

From a email:


private void button1_Click(object sender, EventArgs e)
{
   Customer c = new Customer();
   c.Randomize();


   Customer b = new Customer();
   b.Randomize();


   MessageBox.Show(string.Format(
        “object c random number = {0}, object b random number = {1}”,
        c.RandomNumber, b.RandomNumber));
}


public class Customer
{
   private int random = 0;


   public void Randomize()
   {
      Random r = new Random();
      random = r.Next();
   }


   public int RandomNumber
   {
      get { return random; }
   }
}


If I run the above code without debugging it always returns the same random number, but if I step through the code I get different random numbers.


******


This is a variant of a question that comes up fairly often.


When you create an instance of the Random class, the pseudo-random number generator needs to be seeded with an initial value. Some generators always seed with zero, which means you always get the same sequence of numbers. The .NET Random class seeds using the time, which means you get different results from run to run without having to set the seed yourself.


It also means, however, that if you create two Random instances one right after another, the seed value (I think it uses GetTickCount()) hasn’t had time to change, and you get the same sequence. But if you run it in the debugger, enough time passes between the creation of the two instances that you get different seeds and different numbers.


I think the best solution here is to move the Random instance to a static field:


static Random r = new Random();


And then just use that instance of Random from all the Customer instances.

My favorite driver’s ed moment

May 18, 2006 at 3:23 pm

One of the comments on my last post reminds me of a story.


Back when I took driver’s education  – which would have been the fall of 1979 – one of the modules of the class was spending time in the “simulator”.


I used quotes around term “simulator”, because what it really was was pretend driving. Less like playing a first-person driving game – not even like playing Pole Position – but more like playing with one of these:


But less interesting…


Here’s how it worked.


You sat in a room with about 12 other students. In front of you you had simulated controls – there was a speedometer, a steering wheel, turn signals, brake, and accelerator. At the front of the room there was a movie screen, on which you would watch a movie taken out the front of a car, and while watching, you would pretend to drive.


The sole feedback system consisted of a red light on your console. If the system – assuming it’s not to grandiose to call $2.00 of electronic components a system – thought that you were outside the acceptable parameters, it would light up the red light, and you would come to the attention to the drowsy shop teacher who had to get up at 4:30 to run this thing. I think it also logged your non-compliance, probably using cuneiform.


Each of the consoles had a speedometer, which ran off a motor which got its input from the accelerator and throttle. That helped everybody develop the all-important skill of keeping their fake speed correct.


Rudimentary motor control skills were enough to be compliant in most cases – presuming you could figure out what was coming up in the old, scratch movie. One day we were doing some freeway driving – which meant I was “traveling” at the highly patriotic double nickel – and we got into an interchange to go onto another freeway.


Or at least that’s what I thought it was. But it turned out that it was a right-turning exit that ended in a stoplight. By the time I realized that, I only had about a second before the car was coming to a stop. I spun the wheel, started braking, and as the car in the movie stopped, I looked down, and noticed that my speedometer was dropping through 40 MPH. It took at least another second before it dropped to zero.  I took a deep breath, and waited for the approach of Mr. Schmeer.


And the red light stayed off.


Turns out that the system didn’t check for your speed – only for your inputs. I was on the brakes as I came up to the light, and that was good enough for it. Similarly, if you were turning to the right, it didn’t differentiate how far you turned. You just needed to turn.


Simulator class was a lot more fun after that.

The Seven Deadly Sins of Programmers

May 16, 2006 at 12:53 pm

A while back, I made an offhand comment about something being one of the seven deadly sins of programmers (/programming/developers/software engineering/coding/…).


At the time, I really didn’t have 7 things in mind, but after a little thought, I came up with what I think is a good list.


But before I write the first entry, I’d like you to spend 5 minutes and write down your list of deadly programmer sins. Though 7 is the canonical number of sins, your list can have any number of items. After I’ve gone through my list, I’ll do another post where you can share your list.


[Update: Sorry I wasn’t clearer. Write your list down, and then post it when I’m finished. Or post it now on your own blog if you’d like]

Mom and Apple Pie…

April 4, 2006 at 11:47 am

A few days ago Rory wrote a post entitled Ten Minutes of Sincerity – Enthusiasthma, in which he argues that there is such a thing as too much passion.


Which got me thinking about one of my pet peeves. What do following words all have in common:



  • Passion

  • Innovation

  • Synergy

  • Agility

They’re what I call “Mom and Apple Pie” words, for two reasons.


First, they all have a positive connotation. Who wouldn’t want to be more agile, more innovative? Who is going to argue against having a more synergistic approach? Shouldn’t everybody have passion?


Combine that with the fact that these words are used in a content-free environment, and you get a nice-sounding platitude that means nothing, but makes it sound like you are for changing things.


You don’t think we should have more apple pie? What’s wrong with you? Why do you hate your mother?


People who want to make an organization more agile don’t say, “We’re going to improve agility”. They say, “we’re going to get rid of <x>, we’re going to change <y>, we’re going to release every <x> months”.


People who want to improve synergy say, “Our users are trying to do <x>, and it’s way too hard. What do I need to do to help you fix this?”


With those sorts of people, you can have rational discussions about the benefits and disadvantages of changes.


But don’t talk to me about being more agile or innovative without specifics.


BTW, I’m all for Mom, but I prefer Apple-blueberry, because I like the extra tartness…

Worst… Code… Ever…

March 16, 2006 at 12:24 pm

Like many developers, we enjoy making fun of other people’s code. I’ve had lots of those discussions over the years. And when it comes to who has had to work with the worst code, I’ve never lost.


Way back when I was just out of college – when 7-bit ASCII ruled the world, and people hadn’t decided whether lowercase characters were a fad or not – I worked for a Large Seattle Aerospace Company, at Large Seattle Aerospace Company Computer Services, in a group that built graphics tools for engineers.


One of the libraries that we owned was generated code.


Now, I don’t hate generated code. The Windows Forms Designer and I have a generally felicitious relationship. I even have a patent cube (which you get when an application is accepted at Microsoft) sitting on my windowsill that is related to an architecture for doing generated code.


This particular library was special. It goes without saying that the source to the generator was lost in the card recycling bin of time, but that was not what made it unique.


First of all, it was in FORTRAN. And not that namby-pamby FORTRAN where you can have modern control structures, this was FORTRAN 77, and you had better know how to count spaces and what it meant to put a character in column 6. Did you think that python came up with the idea of significant whitespace? Pshaw.


Secondly, the programmer who had written the code generator was a bit of a FORTRAN afficianado. There’s a feature in FORTRAN 77 known as the “assigned goto”. Here’s an example:


      ASSIGN 30 TO LABEL
      NUM = 40
      GO TO LABEL
      NUM = 50                ! This statement is not executed
30    ASSIGN 1000 TO IFMT
      PRINT IFMT, NUM         ! IFMT is the format specifier
1000  FORMAT(1X,I4)
      END


Now, to understand this, you have to remember that by default, any variable that starts with the letters I-N is implicitly an INTEGER variable (all others are implicitly REAL). So, you can assign 30 to LABEL (this is *not* the same thing as writing LABEL=30, which means what you expect it to mean), and then use “GO TO LABEL” to goto 30.


Suffice it to say that the developer had never read Dijkstra.


Now, my guess is that while the vast majority of you are thankful that you don’t have to work in FORTRAN, there is a divide in opinion beyond that. Some of you are saying “Well, that’s not really that bad”. But the rest of you are shaking your heads, because you know what is coming.


When you’re doing code generation, you need to somehow come up with variable names. In this case, the developer took the easy way out, and all integer variables were something like “I1344”.


And line numbers also use the same range, starting at 1000 and going on up.


So, it means that the code has lots statements like:


GO TO 11634


and lots statements like:


GO TO I1655


Did I mention that in the fonts of the day, the difference between “1” and “I” was fairly subtle? Even if you did notice the I in front, you had to cope with the fact that


GO TO I1655


really meant


GO TO 3455


At least, it meant that sometimes, but I1655 would be re-assigned when the program ran.


IIRC, there were about 15K lines of this in library.


So, bother me not with tales of poorly-formatted C# code or 2000 line C functions. They are mere trifles. To snatch the rock from my palm will require something stronger. Are you up to the challenge?


(I am a bit worried that there might be some LISP or APL programmers out there…)

The capability immaturity model

March 15, 2006 at 11:59 am

I was reading the DailyWTF this morning – a great read, BTW – and came across a link to the Capability Im-Maturity Model, which I thought you might enjoy.

TDD and design methodologies

March 7, 2006 at 1:24 pm

(something I posted on our internal agile alias, in response to a question about how design works in TDD…)


There’s an underlying assumption in software engineering that “more design == better design”, despite that fact that the vast majority of us have worked with baroque systems that answer a bunch of questions that nobody ever asked.

 

The traditional theory is that if you don’t do the up front design, your code will be poorly architected, inflexible, and you’ll be in trouble when you try to maintain it. Which is true. But it’s also true that up-front design – especially the “spend a milestone” type of up-front design – often leads to the same result.

 

The ideal architecture is a minimalist one. It provides all the features that are needed and no features that aren’t needed (I mean “features” in the class method sense, not the user-visible sense)

 

The up-front approach attempts to do that without the data around which features are needed and which ones aren’t needed, which always changes along the way.

 

TDD says, “We’re going to figure out what we need and how to put it together along the way. We know we’re not going to get it exactly right the first time, but with our tests we can refactor as necessary

 

Comments?

Practical Tips For Boosting The Performance Of Windows Forms Apps

March 7, 2006 at 12:18 pm

Practical Tips For Boosting The Performance Of Windows Forms Apps

Over-updating…

February 24, 2006 at 12:23 am

Raymond writes an interesting post about how some programs run faster if you hold down the mouse.


This is a classic situation to get yourself into – I’ve probably seen it 5 times, and hit it again recently.


When we’re burning a DVD, the burn engine calls back into the UI layer so that we can update the progress bar. To give the user a single monotonically-increasing progress bar, we (well, Dean, actually) have to play some games with our progress tracking, which means that sometimes we get progress callbacks once a second, and sometimes we get them 100 times a second.


The progress dialog looks fine, but if you look a profile of the burn, you’ll find that a fair amount of time is being spent in the UI code updating. In this case, it’s not a big deal, but I’ve seen cases where programs are spending 90% of their time updating the UI. That takes a 10 second operation and makes it take 100 seconds, which is pretty bad.


The fix? Well, there are two good ones.


The simplest one is to simply update every <N> calls. I traditionally start with N=10, which is guaranteed to same 90% of the overhead, and usually works fine.


If your callbacks are sporadic – as they are in the DVD Maker case – it works better to timebox the updates. Whenever you update the UI, record the time, and then don’t update it again until a specific time has gone by. I usually find 1/4 second to work well.


 

Resistance to pairing

February 3, 2006 at 11:54 am

Paul wrote an informative response to my post on collaboration.

I’ve just been writing some stuff about where I think our group should go in the future, and I’ve decided to downplay pair programming. Not because I think it’s a bad idea, but more because I think that opinions around it tend to be a bit religious.

Instead, I’ve decided to advocate an open environment where pairing can happen in a natural way