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.


Wednesday, March 13, 2002
 

The true story behind Mosaic and Netscape? http://www.chrispy.net/marca/gqarticle.html. Perhaps if Marc Andreessen was really as imaged Netscape might have won. But MS was better, faster, stronger, and The Race of the Browser went to the dark side.

comment[]

2:50:02 AM    


Flow Chart for Project Decision Making

Not that i'm cycnical, but this is my favorite big picture of how projects work. This diagram is from my c++ coding standards page. Some people have complained about the profanity, but i admire its directness.

In medieval times the majority of developers for all their brain power would have been serfs. Few groups work so hard under such difficult circumstances for the so unworthy. Can't complain about the pay, but that's not all there is. Certainly some of us would be wizards or alchemests or jugglers. A few of us like Galileo would have cracked open the doors of the enlightment and then like Newton blow the doors open. But most of us, myself included i think, would have served our masters quietly tending our fields of code.

                       +---------+
                       |  START  | 
                       +---------+
                            |
                            V            
            YES       +------------+      NO
      +---------------|  DOES THE  |---------------+               
      |               | DAMN THING |               |
      V               |    WORK?   |               V    
+------------+        +------------+        +--------------+  NO
| DON'T FUCK |                              | DID YOU FUCK |-----+
| WITH IT    |                              |   WITH IT?   |     |
+------------+                              +--------------+     |
      |                                            |             |
      |                                            | YES         |
      |                                            V             |
      |  +------+     +-------------+       +---------------+    |
      |  | HIDE |  NO | DOES ANYONE |<------| YOU DUMBSHIT! |    |                 
      |  |  IT  |<----|    KNOW?    |       +---------------+    |
      |  +------+     +-------------+                            |
      |      |               |                                   |
      |      |               V                                   |
      |      |        +-------------+       +-------------+      |
      |      |        |   YOU POOR  |  YES  |  WILL YOU   |      |     
      |      |        |   BASTARD   |<------| CATCH HELL? |<-----+
      |      |        +-------------+       +-------------+
      |      |               |                     |
      |      |               |                     | NO
      |      |               V                     V
      |      V        +-------------+       +------------+ 
      +-------------->|    STOP     |<------| SHITCAN IT |
                      +-------------+       +------------+
      
                              

comment[]

2:20:48 AM    


Big Ball of Mud (http://www.laputan.org/mud/mud.html) is perhaps the best article on the evolution of software ever written. I see it every day. I am maker of mud balls. There. I said it. Please forgive me.

From Big Ball of Mud:

Why does a system become a BIG BALL OF MUD? Sometimes, big, ugly 
systems emerge from THROWAWAY CODE. THROWAWAY CODE is quick-and-dirty 
code that was intended to be used only once and then discarded. 
However, such code often takes on a life of its own, despite casual 
structure and poor or non-existent documentation. It works, so 
why fix it? When a related problem arises, the quickest way to 
address it might be to expediently modify this working code, 
rather than design a proper, general program from the ground up. 
Over time, a simple throwaway program begets a BIG BALL OF MUD.

Even systems with well-defined architectures are prone to structural erosion. The relentless onslaught of changing requirements that any successful system attracts can gradually undermine its structure. Systems that were once tidy become overgrown as PIECEMEAL GROWTH gradually allows elements of the system to sprawl in an uncontrolled fashion.

comment[]

2:07:07 AM    


Excellent article by Martin Fowler on layering systems (http://www.martinfowler.com/isa/layers.html).

comment[]

2:02:26 AM    


Interesting paper on journaling filesystems http://www.informatik.uni-frankfurt.de/~loizides/reiserfs/index.html.

comment[]

1:56:08 AM    



Click here to visit the Radio UserLand website. © Copyright 2002 todd hoff.
Last update: 3/13/02; 1:56: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