He'd be Valentino Rossi. He wouldn't have to create the supreme motorcycle racing being, He already has. Rossi wraps up yet another consecutive world title when it seems the machine doesn't even matter (his Yamaha was and may still be inferior). The competition can't keep up. He passes people at will. What can you say? Sure, God probably wouldn't have dumped it by colliding with Melandri at Motegi (OK, definitely would not have), and God would have won at Laguna Seca and Malaysia somehow. BUT, do you think He could have pulled off that win in the pouring rain at Donnington? No, at least not any better, probably. Maybe.
I try to keep things focused on software development and related biz stuff, but Rossi is The Man. Surely there's a way to relate this to this blog's purpose, but since it's mystifying how he does it, it may forever be disconnected from any reality.
Forza Rossi!
22 October 2005
17 October 2005
The Tuna Speaks Management
Bill Parcels last week, commenting on Drew Bledsoe and Keyshawn Johnson having a sideline spat vs. Philadelphia after a dropped pass:
I don't mean we should all be loose cannons. I just believe there is more to be gained by being frank at critical moments rather than holding back. The people will smooth it out between and among themselves, the organization will benefit.
No, that was nothing. I mean that's nothing. Really, it's nothing. Those two high strung guys -- Actually I had told the team the week before or two weeks before: Hey listen if you don't trust each other enough to air out your differences, you are never going to have a team. If you are afraid of conflict within the team and afraid of confrontation within the team, you are never going to have a team. That's not a team. That's a bunch of guys soaking around wondering what the other guy is thinking. So, I am not saying that I encourage that, I tell them that you have to trust your teammates enough to be able to say what you want to say. If you don't do that, then you are never going to have a team. I have always believed that. You guys know from the teams I had. They weren't exactly uninhibited.Why would I care about what Parcells has to say? His career has all been downhill since his greatest gig as coach of the Giants. Well, he does makes sense. So much sense:
Say what you think -- really, SAY itHow many places are out there where being professional means keeping your mouth shut? Or couching your point in well-laundered language? Or softening a meaning when it's said about the boss? Or working at a place where everyone wants things placid and coated in a smooth, white gloss? Where dissension is an evil thing?
Be in an environment where that is accepted
Hear it, digest it, move on
Use it to get better
I don't mean we should all be loose cannons. I just believe there is more to be gained by being frank at critical moments rather than holding back. The people will smooth it out between and among themselves, the organization will benefit.
12 October 2005
Joel
Love him or loathe him, Joel Spolsky makes software-development-sense. I wish more people would read things like Picking a Ship Date or Set your Priorities. I'm sure Joel is a pragmatic guy, and though I have no idea if he chows on his own dogfood, I find that I sit here and nod and go "uh-huh" when I read him. He's right on.
Software needs to get done. It has to do things that are critical to the purpose, and it should do things that are helpful. It probably should not try to do much else unless it never needs to ship. And make sure it's what the people want—if that's possible. Amen, bruh-thuh.
Software needs to get done. It has to do things that are critical to the purpose, and it should do things that are helpful. It probably should not try to do much else unless it never needs to ship. And make sure it's what the people want—if that's possible. Amen, bruh-thuh.
11 October 2005
Rant: Process Schmocess
In the art of software development with teams larger than one, a process for repeating results is about people. It's about getting them to cooperate and produce something great. That's really it.
I hear groups talk about processes and "resources" (meaning people) and action items and critical paths and all this stuff, and they're full of crap. Their eyes are not on the ball. Management of the process has become the game.
A small group that cranks out great software (meaning it's actually used, it sells, it's profitable, innovative, loved—whatever the criteria for "great" are) and has no process has a good process. If you're a project manager on a team of, say, five people, there is a chance you already have too much "process" smothering your team.
I used to work with a project manager who was the epitome of ineffective. He would try to explain to us something, but it sounded like, "Yeah, we, um, need to review these milestones so we can firm up our deliverables and line up resources so that we can review this with the client at the weekly status meeting and satisfy the action items from last time, too. Alright, see ya." I'd turn to my coworker and ask if he knew what we were supposed to do. "Nope." Me neither.
How about, "Grab Chris, and the two of you get that piece working well enough for us to review it WEDNESDAY A.M. If you have any problems, let me know TUESDAY a.m. and we'll figure out what to do. The client wants an update on THURSDAY. Capiche?"
I hear groups talk about processes and "resources" (meaning people) and action items and critical paths and all this stuff, and they're full of crap. Their eyes are not on the ball. Management of the process has become the game.
"A perfection of means, and confusion of aims, seems to be our main problem." -- Albert Einstein.Groups get together and do things in order to produce software. It has to be useful. It's the result of solving a problem, sometimes a whole bunch of problems. If you have an elaborate "process" and spend all your time in that realm, you are possibly probably losing sight of the goal -- great software.
A small group that cranks out great software (meaning it's actually used, it sells, it's profitable, innovative, loved—whatever the criteria for "great" are) and has no process has a good process. If you're a project manager on a team of, say, five people, there is a chance you already have too much "process" smothering your team.
I used to work with a project manager who was the epitome of ineffective. He would try to explain to us something, but it sounded like, "Yeah, we, um, need to review these milestones so we can firm up our deliverables and line up resources so that we can review this with the client at the weekly status meeting and satisfy the action items from last time, too. Alright, see ya." I'd turn to my coworker and ask if he knew what we were supposed to do. "Nope." Me neither.
How about, "Grab Chris, and the two of you get that piece working well enough for us to review it WEDNESDAY A.M. If you have any problems, let me know TUESDAY a.m. and we'll figure out what to do. The client wants an update on THURSDAY. Capiche?"
06 October 2005
IT Conversations
This site is a great place to get webcasts or podcasts (or what you will call them) to learn something on your long commute. Download some of these to your music player, start with the highest rated ones. Good stuff.
04 October 2005
AJAX is the Word
I'm late to this. AJAX (courtesy of Microsoft, and see those guys at Adaptive Path) might be the thing that finally kills off desktop applications once and for all. The time we spend building setup programs, planning updates that don't do unplanned carnage, and duplicating things when we need both a Windows and web app is astounding.
It's interesting to see how Microsoft, the inventor of XmlHttpRequest, made this possible and then left it out there for others to run with. Now, because of the bewildering flavors of and platforms for AJAX—that is, a lack of a standardized approach—Microsoft may yet wrest control of this from the masses with ASP.NET 2.0 and Atlas. And criticism like this is going to help Microsoft take some of these people by surprise, because they don't get what they think they get. Again.
We can dink with Javascript calls to the server and sew together script.aculo.us and AJAX.NET or DOJO or, man, you name your cobbled together toolset. But this is like version 0.53871 of Web 2.0. We're soon going to look back on this as we do on Windows API programming. A standard way of coding this on the server side is needed. Maybe Microsoft will have the answer, but I shudder to think of how horrid the Javascript generated by Atlas is going to be.
It's interesting to see how Microsoft, the inventor of XmlHttpRequest, made this possible and then left it out there for others to run with. Now, because of the bewildering flavors of and platforms for AJAX—that is, a lack of a standardized approach—Microsoft may yet wrest control of this from the masses with ASP.NET 2.0 and Atlas. And criticism like this is going to help Microsoft take some of these people by surprise, because they don't get what they think they get. Again.
We can dink with Javascript calls to the server and sew together script.aculo.us and AJAX.NET or DOJO or, man, you name your cobbled together toolset. But this is like version 0.53871 of Web 2.0. We're soon going to look back on this as we do on Windows API programming. A standard way of coding this on the server side is needed. Maybe Microsoft will have the answer, but I shudder to think of how horrid the Javascript generated by Atlas is going to be.
Subscribe to:
Posts (Atom)