"APL is like a diamond. It has a beautiful crystal structure; all of its parts are related in a uniform and elegant way. But if you try to extend this structure in any way - even by adding another diamond you get an ugly kludge. LISP, on the other had, is like a ball of mud. You can add any amount of mud to it and it still looks like a ball of mud." -- Joel Moses

"Project management is like a muddy diamond. It looks messy, dirty, and worse than useless from the outside, and contains an elegant structure on the inside. Unfortunately, if you wash the mud off to get a good look, or to make it pretty, you expose razor-sharp facets on which you are certain to cut yourself badly." --Strata Chalup

The Muddy Diamond Bar & Grill
A log of pointers, practices, war stories, and miscellany, documenting the author's increasing involvement with software project management in specific, as well as project management in general.

Links: Project Mgmt Resources

Other Blogs by Strata

JDYDJ: The Sysadmins Corner

Patterns in Systems Administration

Scale Away: Solving C10K

It Works for Me-- Stuff I like, use, or recommend

FYI-- Useful and interesting things to know

Radio Free KF6NBZ-- Amateur Radio kibbles and bits

Strata's BayLISA Working Area

Mobilis in Mobili-- Changing in a Sea of Change
This page is powered by Blogger. Isn't yours?

Friday, March 02, 2001

Is your office a "White Collar Sweatshop"? Do you protect the folks you are managing from having their lives taken over by work, or do you think it's just part of the job?

Tuesday, February 20, 2001

What in the world is a link like Tips For The Performing Songwriter doing in a project management and software engineering blog? Great question.

You can put yourself in the viewpoint of a product manager or consultant, and most of the 31 tips will apply to you and how you manage, interact with the teams, etc.

You can put yourself in the viewpoint of the product itself, anthropomorphize it, and most of the 31 tips will apply to you and how you define yourself, what your interaction with the users is like, how to keep the basics working, and how not to fail on technicalities.

As a bonus, you can put yourself in the viewpoint of someone in technical marketing or product marketing, and most of the 31 tips will apply to you and show you how to present a product and what things to care about and how to learn from mistakes.

Or you could have a knee-jerk reaction and say, "This is stupid, it's not even about project management or software development!" Your choice!

Saturday, February 17, 2001

Fair Measures

These pages have in-depth information on various issues such as overtime, wrongful termination, disability law, and so on. The folks hosting the pages are also providing services for pay, such as seminars and training, but they have encapsulated a lot of good info into the web pages here.

Friday, February 16, 2001

By the way, I blogged too quickly on that one-- the paragraph describing Ruby should be quoted, it's the first paragraph in the article "A freely available pure object-oriented language", by Dave Thomas and Andy Hunt in the January 2001 Dr. Dobbs. That's where the link goes.

Jan01: Programming in Ruby

Take the pure object orientation of Smalltalk, but remove the quirky syntax and reliance on a workspace. Add in the convenience and power of Perl, but without all the special cases and magic conversions. Wrap it up in a clean syntax based in part on Eiffel, and add a few concepts from Scheme, CLU, Sather, and Common Lisp. You end up with Ruby.

Ruby Home Page

Will the "real" Ruby homepage please stand up? Ok, it's this one.

What is Ruby?

I haven't actually sat down and learned Erlang. I wonder if I'll sit down and learn Ruby? :-) Then again, I've never learned Perl, either....

Friday, January 12, 2001

"For Best Results, Forget the Bonus" by Alfie Kohn, author of "Punished by Rewards". An interesting and rather valid looking take on how rewards just lower the bar for performance. Very unconventional thinking. I need to read his book and see if things like across-the-board rewards (offsites, all-hands bonuses, etc) count as well.

Sunday, January 07, 2001

CRC Cards This interesting approach to software design looks suspiciously like an undocumented approach to systems integration called "Taskflow Diagrams" that has been developed by yours truly over the past several years. It is also a Design Pattern on the main C2 Wiki.

Don't know what a Wiki is? Heh. Have fun, they're great. "Wiki wiki" is Hawaiian for "quick". Wikis are a quick collaboration environment based on forms-driven user-editable web pages. They're also something of a way of life for some system development cultures. They don't seem to have caught on heavily in the project management or systems administration worlds yet, but maybe we can fix that. :-)

ProjectZone describes itself as "a community of technology project leaders discovering, learning, inventing, and teaching each other better ways to lead and manage teams and projects." I'll buy that. Very rich and deep site, highly useful. Another similar site is the New Grange Center for Project Management. Their online library is extremely impressive and useful.

What's really scary is how many people I talk to who think that these things are not really issues, usually "because that's so improbable" and "companies aren't going to do that", and are then surprised when I point them to websites and news stories. The Top 10 Privacy Stories of 2000 Workplace Surveillance is the Top Privacy Story of 2000 Other Top Stories include Medical Privacy, Carnivore and DoubleClick

Saturday, January 06, 2001

Very nice, and lots of pointers to similar documents... Why Johnny Can't Encrypt: A Usability Evaluation of PGP 5.0 - Whitten, Tygar (ResearchIndex) Why Johnny Can't Encrypt: A Usability Evaluation of PGP 5.0

Tuesday, January 02, 2001

Mining Usefulness - A Philosophy of Function "Starting from the <1>principle that we were intended to be useful, and so have an instinct to seek usefulness, the author seeks to <2>explain the phenomenal growth of the Open Source and related movements. An attempt is then made to <3>assemble a vision (seen as if dimly through a small window) of where this is taking the computer industry and perhaps society as a whole." -- Leon Brooks, QBX

Other folks who are already doing things in this space include:

Dot Net Dan's Dot Net Discussion, focused on .NET development and a mix of language/programmer stuff and software development methodology and practice stuff. I like it so far!

Joel on Software What more can I say than, "all bow to the master!". Rich as well as deep, since Joel's been logging things for a long time. I've spent whole afternoons reading here.

"While much attention has been focused on high-level software architectural patterns, what is, in effect, the de-facto standard software architecture is seldom discussed. This paper examines this most frequently deployed of software architectures: the BIG BALL OF MUD. A BIG BALL OF MUD is a casually, even haphazardly, structured system. Its organization, if one can call it that, is dictated more by expediency than design. Yet, its enduring popularity cannot merely be indicative of a general disregard for architecture.

These patterns explore the forces that encourage the emergence of a BIG BALL OF MUD, and the undeniable effectiveness of this approach to software architecture. What are the people who build them doing right? If more high-minded architectural approaches are to compete, we must understand what the forces that lead to a BIG BALL OF MUD are, and examine alternative ways to resolve them.

A number of additional patterns emerge out of the BIG BALL OF MUD. We discuss them in turn. Two principal questions underlie these patterns: Why are so many existing systems architecturally undistinguished, and what can we do to improve them?"
--Brian Foote and Joseph Yoder