Stupid Human Programming
Talk on software development.








Click to see the XML version of this web page.

Click here to send an email to the editor of this weblog.


Sunday, March 17, 2002
 

Differential Diagnosis is an innovative technique for finding bugs. It's a strategy a co-worker of mine uses that is so obvious in retrospect, yet has an incredible amount of power.

Usually problem debugging starts from scratch everytime and our heroes eventually find the probem. Using Differential Diagnosis you go back and look at the change history for every change since the bug wasn't a bug. The idea is that the code worked at one time. The bug is likely to have been introduced in one the later changes.

By inspecting the source of only the changes it's often possible to figure out the problem or at least narrow it down considerably.

This approach makes a lot of sense and works extremely well. But i hadn't seen it before. Obviously no strategy will always work, but it works a lot of the time. Even well unit tested code can have intregration related bugs that don't show up until later. And many products are so complex that any unit test doesn't scratch the surface of possible tests.

Since then i've read a paper where the build system after finding a bug from a smoke test run would automatically backout changes and rebuild until it found which change caused the bug. Very cool. Someday i hope to add this to our current build system.

comment[]

12:58:40 PM    


IEEE Software article Server-Side Design Principles for Scalable Internet Systems by Colleen Row and Sergio Gonik of GemStone Systems is a good overview of different strategies for achieving scalability. http://computer.org/software/index.shtml. It has the principles of scalable architecture as:
  1. divide and conquer - system should be partitioned into smaller subsystems that can be deployed onto separate process or threads, which disperses the load and allows for load balancing and tuning.
  2. asynchrony - means work can be carries out in the system on a resource-available basis. Asynchrony decouples functions and lets the system better schedule resources.
  3. encapsulation - system components are loosely coupled with little dependencies among the components.
  4. concurrency - Activities are split across hardware, processes, and threads and can exploit physical concurrency of modern multiprocessors. Concurrency allows the maximum work to be scheduled.
  5. parsimony - Designer must be econimical in what they design. Pay attention to the thousand of micro details.

Strategies for achieving scalability:

  1. Careful system partitioning
  2. Service-base layered architecture
  3. Just-enough data distribution
  4. Pooling and multiplexing
  5. Queueing work for background processes
  6. Near real-time synchronization of data
  7. Distributed session tracking
  8. Keep it simple

And lots more with a lot more detail on each topic. It's a very good overview discussion that jibes with my experience. The question is how do developers implement all this, which is where i assume GemStone comes in :-) A part of scalabily that doesn't get addressed is ordered syncronization between distributed applications that can fail and recover independently. Maybe more on that later.

comment[]

7:38:39 AM    



Click here to visit the Radio UserLand website. © Copyright 2002 todd hoff.
Last update: 3/17/02; 7:40:08 AM.
March 2002
Sun Mon Tue Wed Thu Fri Sat
          1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31            
Feb   Apr