blog.jj5.net (2003 to 2005)
Mark Baker vs. Don Box. Round One.
Thu Oct 14 17:18:00 UTC+1100 2004
Oh, you go girl! :D
I wish all programmers realised that programming is all about managing complexity. (The complexity inherent in 'doing stuff with things and lists of things').
The only effective way to manage complexity is through constraint.
That's why I spend my time complaining about things that try to do too much. Can we say: IDisposable. You need constraints on things if you want them to be useful.
Unfortunately MS spends their time trying to 'do what the customer wants' (so they would have you believe) and when the customers are the 'mindless VB legions ;)' who just want to be able to 'stick a print button here' the results can be less than pleasing.
Grrr.
I'm continually shocked and amazed at how poor a grasp so many heavy hitters seem to have on this. I'm convinced they must be running a corporate agenda of designed obsolescence, because they keep making the same mistakes disguising them by a change in appearances (but not in substance).
Here's a few tips:
- Interface is contract (hint: classes, interfaces, URIs, are all Interfaces (whether or not they are good ones is up to you))
- Don't program by side effect (a method returns a value and changes nothing, or returns nothing and changes something).
- Throw away state managed by a module that throws an exception.
- Don't assume anything! Assert your pre and post conditions. Guarantee to work if your invariants hold (otherwise a software failure is your design fault).
- Assert with 'assertions' for private bits and leave them in during testing.
- Assert with 'exceptions' for public bits and leave them in all releases.
- Stop time when you make your assertions. Asynchronous programming is hard! (hint: be in a sole execution context, or own a lock or transaction).
- Exceptions ARE ERRORS. Political correctness and diplomacy are not useful for you as a programmer.
- A network card does two things: send and receive. A hard disk does two things: read and write. RAM does two things: read and write. There's something in that for all of us.
- Do one thing well.
- Program for correctness first, performance later (read: never).
- Keep it simple stupid.
- You ain't gonna need it. Maybe. You ain't gonna want it. More likely. You definitely don't want it. Almost certainly.
- Indirection is your friend. Find a pattern.
- Use the principle of least privilege. Private? No? Then internal? No? OK: public. Interface, sealed, abstract, virtual.
- Don't kludge things. It costs you more in the long run. If it has to be done, then it has to be done. If it's worth doing, then it's worth doing well.
- Fail safe: Fail fast.
- Don't share! If you do, take the time to understand ownership. Respect the commitment you are making when you expose a public interface. Try to avoid it.
- Data is a read lock.
- Four words: BCNF.
- Know what things cost? Sure. More importantly: Know what things MEAN.
- Functional cohesion.
- Loose coupling.
- Subsystems might have lots of moving parts, but they should be connected with the smallest set of 'contact points'. Obviously there's friction at a point of contact and it's a solid engineering principle to keep them not only well lubricated, but also highly constrained, heavily isolated, and well understood. Put your safety features there. You can plug bits of Lego together in different ways, but the interface is always that short, round peg and matching hole. Some Lego flashes. Some doesn't. (Of course, a block of Lego has functional immutability. It guarantees its well known contract for all time. Lego block v3.7 might have different coloured, faster flashing lights, but you can bet the point of integration will be the same constrained peg/socket pair and you don't pretend you won't have to do some plugging/unplugging to integrate it into your design (Metaphors are fun!))
You'll have to deal with the following at various levels of granularity:
- Interface based programming.
- Optimistic concurrency.
- Business model. (hint: Don't use an 'entity model', or a 'domain model'. Use a 'document model', but don't leave it until you're in the UI to do so (put your 'document model' in front of some sort of DAL, you can call this the 'entity model' or 'domain model' if you like)).
- Request => Response.
Have fun!
On the attitude of Microsoft People (TM): I couldn't believe Chris Sells's comment the other day. Um, so, paraphrasing: “We're innovating! We're leading! BTW: thanks for continually giving us your ideas, and wasting your time listening to us; please keep it up. No we're not sharing with you. Bitch.“ Yeah.. nice one.
A complex system that works is invariably found to have evolved from a simple system that worked.
-- John Gall
re: Mark Baker vs. Don Box. Round One.
Ruben Bartelink on Fri Oct 15 11:50:00 UTC+1100 2004 said:
s/hoards/hordes/
re: Mark Baker vs. Don Box. Round One.
John on Fri Oct 15 12:04:00 UTC+1100 2004 said:
Thanks Ruben. :P