Previous Entry Share Next Entry
happy
yesthattom

(no subject)

I heard an interview with the guy that invented (popularized?) Extreme Programming. He said when he was working on Design Patterns he spent a week where we wasn’t allowed to write a line of code without being able to first name the pattern he would be using. He found (and fixed) tons of gaps in his pattern language. It made me think: could we do the same for system administration?

  • 1
There would be much gripe about the theoretical-ness of it. Just think of the long-standing argument about who's better, those who have an educational background in IT or those who don't?

However, I believe that yes, it could be done, and probably should be done...although there are probably more "emergencies" that can't wait to have that thought process involved.....

What are the design patterns for SA, anyway?

Well, I have some ideas but nothing firmed up yet.

My first book (TPOSANA) is basically all design patterns, but we didn't think to give each one a name, precondition, desired outcome, etc. etc.

Tom

If your patterns do not include http://en.wikipedia.org/wiki/Poka-yoke then I would say they are not yet complete.

The field of process improvement has lots to say on much of what we end up reinventing... poorly.


thanks! i 'll add that to the list!

Simiarly, design patterns for networks, but not just topologies. Operational design patterns for networks or systems would be fascinating.

For example, patterns like:
"No Logging In" // mostly for network stuff, where netomata would be useful
"Disposable Systems" // Blowing away systems is easy/routine.

I'd love to talk more about this with you, if you're interested.


Sure! Ring me or email me.

He said when he was working on Design Patterns he spent a week where we wasn’t allowed to write a line of code without being able to first name the pattern he would be using.

In the early 1800s, grammarians looked at common usegae, combined tehir observations with personal prejudices, and came up with various 'rules' of English such as "Never start a sentence with a preposition." Although rea rules, which should almost never be broken, exist, the best writers have never followed many of those academically generated, inorganic rules.

True -- this is like good jazz music (or any good music probably) -- you can't really put a formula to it.

However, most grammar rules exist for a reason -- usually following the rules helps clarify meaning. Similarly, finding patterns and applying them to programming or administration is a start to make things better.

I agree that blindly following the rules isn't good for writing nor for administration...but having patterns in the first place would be a first step. The reason for having grammar rules is for clarity of meaning. The reason for having programming design patterns is to make better code (more optimized, more readable, etc). The rules should be organic, sure, but I don't think those reasons are good enough to not have the patterns/rules to begin with.

I like that "rules were made to be broken" but if you don't have rules, all you have is chaos.

Dvd, the grammarians were very different. The entire Patterns Language movement has had to work against this kind of argument for decades. The goal isn't to make hard-fast rules, but to record the tacit knowledge that experienced people have.

The introduction to this book explains it really well:

A Pattern Language

When Hogan and I initially started telling people what we intended to write in TPOSANA we were often told "that's impossible! it isn't possible to explain to people how to do such-and-such. You either know it or you don't!". I think we did a good job of putting those things into words. :)

I'm not arguing against the development of rules. Just be careful that the rules don't become primarily tools for pointy-headed bosses to act like they know what they're doing while they're actually gumming up the works. I think if you ask many programmers about their experience of the late 1990s, you'll find that's how design patterns were often applied to the real world.

I disagree with none of what you said. I just caution taht programming around the turn of the milennium passed through a time when the rules were taken by those who should have known better to be ends unto themselves. I'm now out of the business, but from reading about it, I think it's gotten better, in part thanks to the Extreme Programming guys. Spolsky has also helped, I think. So for sure, develop the rules, but take care not to let them the zeitgeist get away from you.

I think it'd work in some environments, but as we discussed in email the other week, there's still a lot of people out there who are considered senior sysadmins and don't get sysadmin fundamentals like code reviews.

As awfief pointed out, just the perception that it's theoretical and academic would scare off a lot of people (particularly the crowd who do things like write scripts individually on machines rather than writing them sufficiently generically, checking them into a central repository and packaging them for distribution because it's "faster").

I would argue that code review a complex combination of several things.

1) doing things simply enough to verify by simple inspection.
2) making sure there are no mind SPOFS.
3) having a third party check on your whatever it is your doing.


Also depending on the region of system administration code review is in fact an alien monster. When your deep in the burning building you don't ask your fellow fire fighter to insure that your next ax blow is optimal. Many sysadmins operate in a brutal brutal firefighting regime. Where elegance and correctness are often low priority goals.



  • 1
?

Log in

No account? Create an account