and another site to add to our list of one page wonders. This time around it’s Is IE6 Older Than Your Grandpa?
Ain't he a cutie?
Sadly, no highly entertaining wackaloonery in the source, but you can’t have everything. Could also use a little tweaking on the layout (unless, of course, the designer is making a statement about the horrors of IE6 dev and the disaster that is CSS compliance, in which case, good on you).
For some reason, today I was reminded of a chemical spill at my high school and how it served as a pretty good metaphor for my current situation. A container of a corrosive liquid was improperly sealed and stored on a wooden shelf. No one paid any attention to it, but the gunk on the container was slowly eroded the shelf. Until one day, the shelf broke, leading to a rather nasty spill. Broken containers, more broken shelves, potentially unpleasant chemical reactions—it was a really toxic situation (haha). The students got sent home; guys in hazmat suits got sent into the chem lab closet. No one was injured, but that was just luck. All because of one mistake, the badly sealed container, and a series of missteps by those responsible for the storage of the chemicals.
So how does this relate to the office? Consider this—you have a guy on a team who doesn’t complete his tasks, misrepresents his progress on those tasks, berates other members of the team members publicly and complains, mostly baseless, about other members of the team to their supervisor without any repercussions (to himself, certainly plenty for the team). The supervisor takes our toxic guy’s word at face value, for both his efforts and his attempts to improve his position at his teammates’ expense, even after members of the team have approached the supervisor repeatedly to discuss the situation. Here we have our toxic container, let’s just call him Guy, and the well-meaning but inept storage manager, our team supervisor. Toxic ick is leaking all over the shelf (our project) and no one pays attention.
Until one day, the shelf breaks. All of the damage Guy has done has left the project in ruins and team morale nonexistent. But, because most members of the team are also involved with other projects, the collapse of the one project has led to damage to other projects (the shelves below the original break). Here’s the problem, though, there’s no hazmat team to come save you. If the supervisor doesn’t recognize the damage and doesn’t take any steps to refocus the team and get the project back on track, odds are, the project will fail. I suppose that’s a lot to ask; if the supervisor was that clueless in the first place, there’s really not much chance that they’ll understand how to pick up the pieces. Toxic guy’s effects will continue to damage other projects. The pieces aren’t going to pick themselves up, rebuild the shelf, and generally tidy up.
I don’t have any solutions. The shelf broke months ago and no one has even really noticed how broken everything is. Clearly, it’s better to nip it in the bud. Ignoring the concerns of the majority of the team hurts morale; ignoring the repeated delays hurts the project; telling the other team members that that’s just how Guy is is just infuriating. I don’t know how you can have any trust in the supervisor after that. It’s not like there’s a switch for the next project to all of the sudden trust the supervisor again. Simply ignoring the problem will not make it go away.
Quick tip – when ModelBuilder (ESRI ArcGIS) starts pulling the whole invalid input/input tables don’t match rigamarole, it doesn’t seem to help to just run the validator or restart ArcMap. At least for my last model marathon, it actually wouldn’t run until the computer was rebooted. And now, no problems. Just another bit of wacky weirdness for ArcGIS.
I moved a few years ago from a large metro area to a medium-ish metro area. My commute dropped from 25-45 minutes each way to just over 5 minutes. Hooray for me, I’m saving the world! Well, at least some carbon. And even though it’s cut down on the driving and the gas bills, it’s come with a bit of a downside. I used to resolve a lot of design and coding issues driving and now I’m home and focusing on other things before the brain can wrap around the day’s fun. I haven’t found anything else to replace that nice chunk of time.
Alternatives for inspiration while driving:
There must be other minimally distracting tasks that leave enough room for problem-solving out there. I definitely don’t want to shovel more snow than I have to.
There is a difference between being the project manager and being the only developer on the project. Note that I did not say the only person on the project. Viewing the developer as the project manager is just asking for disaster (unless that person is the most awesome ultra-with-it developer/designer/PM ever). But even if you had that developer, you’re still in trouble, especially in an academic environment.
Consider a project to develop some GIS extension/toolset to be completed in a year. The group consists of three PIs (tenure-track/tenured/postdoc), a developer, and maybe some students (let’s say masters students). It comes with a built-in hierarchy—tenured > tenure-track > postdoc > masters students > developer (masters students and developers, as technical/professional staff, might be at the same level; it depends on the department and the PIs). The students may or may not be involved in the actual coding; odds are, they are more involved in the data collection and general scutwork. The developer is declared to be the project manager. Let’s also add the stipulation that the developer is also acting in a GIS analyst role, so any GIS data needs would be defined by the developer.
The needs of the toolset are defined by the PIs—it’s their grant. The actual structure and technical details are defined by the developer, who is also acting as the main designer (mostly UX in this case), database admin, tester, and technical writer. The students may have some research needs of their own for the thesis work, but are otherwise there to do what needs to be done.
So that’s the setup. Remember that here we are just talking about the potential pitfalls of declaring the developer as project manager. So how would it go?
Probably not terribly well. You can guess why—three little chieftains who each have a vision of the project, whatever it might be, approaching the developer with changes to the design, changes in the priorities, changes to the underlying purpose of the tool. And, although the student is nominally under the charge of the developer (being the project manager), it’s academia; the students belong to the advisors. So at any time and for any reason, the students can be moved to some other task for some unknown amount of time, regardless of the stated priorities. The plan, particularly the schedule, is completed disregarded. This is more likely to occur when the plan is put together by the developer. It wasn’t the little chieftains’ decisions; it’s not their schedule; it’s just not respected (experience just can’t beat the raw PhD). The PM can’t define roles, can’t assign tasks, can’t keep the project moving forward beyond those pieces they are personally responsible for.
Project management at that point has devolved into the developer’s own time management practices, constant revisions and juggling of the tasks and schedule, and constant stress from never knowing if the students will deliver any of the work that’s required (let alone anything usable; they’re students so that’s hit or miss anyway) and the little niggling worry that the next phone call, knock on the door, or email chime will undo hours, weeks, or even months of work on a whim. And, of course, since this is an academic environment and it’s not uncommon at all to have to work long hours to meet a deadline, there’s nothing wrong with expecting the developer to do that.
I’ve heard this type of situation described as agile programming before. Agile’s all about iteration and change and flexibility, right? To those people not laughing on the floor right now, I say this—no, no, no, no, no. It is not project management. The situation does not improve by misclassifying bad management with the method du jour of the week. Getting something that works, kinda sorta, at the end of the project does not mean that the project goals were reached. And saying things like the developer just doesn’t handle stress well or doesn’t actually know how to manage a project, well, that’s just pathetic. It’s petty and small-minded. And it won’t help the next project or the one after that or the one after that if you can’t or won’t evaluate honestly everyone’s role in the project. Giving someone a title to make it easier to blame them later is just crappy.
So what’s the solution? Well, maybe one of the PIs should take on the role of manager, since they are in fact the project manager. Maybe have regular meetings where the current status of the work is discussed rather than just chucking out tasks at people willy-nilly. Have everyone at the meeting, so there’s no confusion as to what is happening when. And the standard project management spiel with clearly defined goals, clearly defined roles, a process in place to deal with modifications to the plan, etc.
And to the PhD-holding folks—you are doing a great disservice to your students. They will have to go out and manage their own projects. Manage their time between family and teaching and researching. Some management skills certainly wouldn’t hurt. Being able to respect people in other fields with different experiences does not hurt.
Well, they’re no Canadians (with the always funny Corner Gas), but whoever thought that replacing the Microsoft error messages with haikus in Japan ranks pretty high on the comedy scale.
A crash reduces
Your expensive computer
To a simple stone.
This happened twice this morning:
Chaos reigns within.
Reflect, repent, and reboot.
Order shall return.
The fate of my master work schedule:
Having been erased,
The document you’re seeking
Must now be retyped.
which I did not retype. Too depressing.
Pick a flash drive or the Program Files partition (hint, IT boys, 10GB or even 20GB is not enough in these days of massive MS bloat):
Out of memory.
We wish to hold the whole sky,
But we never will.
Lost count after the morning’s crashes:
Program aborting:
Close all that you have worked on.
You ask far too much.
Pick a day, like tonight at 9 on the drive back to the office to reboot the piece of junk:
Serious error.
All shortcuts have disappeared.
Screen. Mind. Both are blank.
Oh noes, where did SharePoint go!?
Stay the patient course.
Of little worth is your ire.
The network is down.
When the Google-fu fails me:
The Website you seek
Cannot be located, but
Countless more exist.You step in the stream,
But the water has moved on.
This page is not here.
So every time the thing crashes or the app borks:
Three things are certain:
Death, taxes and lost data.
Guess which has occurred.
I think I might get this on a shirt for Halloween. So much scarier than some random zombie.
Windows NT crashed.
I am the Blue Screen of Death.
No one hears your screams.
Because, really, why would it be where you left yesterday?
With searching comes loss
And the presence of absence:
Your file, not found.
Windows and coding:
Yesterday it worked.
Today it is not working.
Windows is like that.
Size matters:
Your file was so big.
It might be very useful.
But now it is gone.
until it’s gone.
via Let ε < 0. via Laura RuneMercury H.
Remember the ski school instructions for the n00bs? Pizza to slow down and french fry to speed up. I was thinking about that the other day during a run of shifted priorities and server disasters. I think we need a similar analogy for project management—cheetah and ostrich. Cheetah for the lean, mean, effective plan; ostrich for the haphazard, awkward lack of planning.
Cheetah! I have a plan. I see the end point. We’re going to make it! We are on fire!
Ostrich! Oh noes! The program doesn’t work. Maybe if I ignore it, that stack trace will just go away.
Cheetah! Dude, we are on fire!
Ostrich! Is that smoke pouring out of the server?!
Not quite the same as pizza and french fry, but you get the idea.
Consider working for people who always take the ostrich approach to PM. And then extend the lack of planning to an inability to consider all of the projects and the priorities when responding to new requests or problems. Or even bouncing between the two states—frustration city with disaster lurking in the burbs. Then there’s no time to plan, no time to think things through and the cycle continues because now you have to keep going back to redo things that were close but not quite right due to the lack of planning. But it also speaks to a failure in communication and to fear. If you don’t make a plan then there’s really no reason why the failure is your fault, but once your name is in there as responsible for some or all of the project, well, that’s pressure. And thus the fear.
What they (the planless) don’t realize is that having a plan is like a fear quencher. You know what to expect, at least in somewhat broad terms; you know who to go to for each part and you know what you’re going to get at the end. Far less scary than contemplating the great unknown of your project. So avoid the disastacle* and make a plan. And then follow the plan. That last part is just as important.
* still my favorite disaster term. Hooray, Better Off Ted!
So some engineering student used the StackOverflow.com data to see if C# and Java were ’serious’ languages (i.e. languages that people used mostly at work) and Python and Ruby on Rails were ‘play’ languages (languages people used for fun). He figured that you would see this in the search terms – C# and Java during the week; Python and Ruby on Rails on the weekends. Here’s what he came up with:
StackOverflow results (normalized)
And then there’s some talk about big spikes on weekends and on Mondays. I’m not seeing anything that screams statistically significant. So I went to Google Trends for outside corroboration. Here’s the results for the last 30 days:
C# (red) v Java (orange) v Python (purple) v Ruby on Rails (green) v Lego (blue)
and threw in Lego, working on a similar assumption that more people would look up Lego on the weekends. Seems pretty clear—searches for C# and Java drop on weekends (and you can ignore the blip on the lower chart—that was related to the island of Java); Python and Ruby not so much; and Lego goes up on weekends. Not even remotely scientific, but I think a clearer case for C# and Java being used more for work than play given the dropoff. Obviously, for a real comparison, one would need better data for Python and Ruby on Rails in particular as well as a filter to remove Java the place from Java the computer language. I like that there are more searches for Lego any day of the week than there ever are for C#. That’s awesome.
At some point, the internal checklist got reset. All of the required steps are completed except for the very last one—copying the files to their final destinations. (Yes, I know it could be automated; it is just not a priority for anyone else these days.) It only took forgetting that one step twice for it to become not just possible but probable. This is not good.
Pretty standard boiler-plate until you get to:
If shelter is not available, lie flat in a ditch or other low-lying area. Do not get under an overpass or bridge. You are safer in a low, flat location.
Uuurrghhh… pffft. My head just exploded from teh awesomeness of this advice. At the next bug report, I will duck and cover. With the kit that I made for cyber emergencies—two cans and some string, a tin of caffeinated mints, a megaphone (because I’ve always wanted to respond to “I am on the phone” with “But I am on the megaphone” like Beth from NewsRadio and because that is the closest analog twitter equivalent), and my two plush microbe brain cells. You never know when you’ll need two to rub together.
