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
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. :-)
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