Golly gee, the Cranky Product Manager was recently quoted a few times in the ZDNet blog, The IT Grind. As was Saeed “Wrath of” Khan, the esteemed author of THE blog On Product Management.
The title of the ZDNet piece was “10 things your IT project manager never wants to hear.” Confusing that the CPM and Mr. Khan should both be featured, as both write about proDUCT management at software manufacturers, not proJECT management within corporate IT departments. But whatever. The CPM will take any publicity she can get.
Anyway, ZDNet just shared a few snippets of the Cranky Product Manager’s distilled wisdom. You, darling readers, deserve more. So here’s the CPM’s entire rant, as sent to Deb Perelman at ZDNet.
Three Things the Cranky Product Manager Never Wants to Hear a Developer Say. Ever.
1) “The product needs to be re-architected from scratch”
Re-architecting, it seems, is every engineer’s wet dream. How could an engineer possibly be expected to understand the code their predecessor wrote? Better to tear down the entire house — even though its residents are perfectly sheltered – in order to remodel the bathroom or put a cover over the patio.
Really.
Re-architecture seems to always be necessary because the predecessor never knew “what the hell he/she was doing”. Somehow the profession is littered with an innumerable number of idiots, except for the one currently doing the talking. If you believed the engineers you’d conclude that programming languages were all “WORN” – Write Once, Read Never.
Scratch that. Make it “WMRN” – Write Many Read Never.
2) “It’s technically impossible”
In the Cranky Product Manager’s experience, engineers only claim the really boring stuff is technically impossible. In contrast, the truly out-there stuff (building a warp drive, increasing Dubya’s approval ratings) is described as “potentially do-able, if only …”. Funny that.
Saying something is “technically impossible” makes marketing and non-tech types tremble like an espresso junkie. But fortunately the Cranky Product Manager has a solid code-slinging background and can call bullshit. Perhaps the WAY the engineer thinks is the Ideal is technically impossible, but almost always the customer requirements can be met via a different, more earth-bound implementation.
But too bad, the project will still be boring.
3)When a developer argues that a particular product component is PERFECT for implementation via the latest fad of development technology.
“Cranky Product Manager,” they say, “we should implement this high-speed encryption system using Ruby with an AJAX front-end. It fits PERFECTLY.”
What crap.
First, in most cases the fad technology most certainly does NOT fit the problem.
Second, we’re under a deadline here! This thing needs to be DONE in 2 weeks and we don’t have time for the developer to learn the latest resume-enhancing technology on the job while that clock is ticking. And besides that developer’s slower speed, the QA team would need to figure out how to plug that new technology into their automated systems. The IT department has to figure out how to get the latest versions of the proper development tools on everyone’s desktops. Other team members need to learn the FAD Tech too, in order to do code reviews or pick up the code when that developer is sick or incapable of fixing his own bugs. The ripple effects are huge.
Don’t get the Cranky Product Manager wrong. Adding a new technology to the mix is often warranted, but it is not a decision to be taken lightly — most certainly not on some developer’s whim. Have the whole team consider FAD Tech in the planning stages of the next biggish release.
In the meantime, tell your developer to go screw around with FAD Tech at the next SuperHappyDevHouse or something. Just pray he doesn’t whip up some piece of s@#$ hack and expect you to stuff it into the product at the last minute.
{ 4 comments… read them below or add one }
RE-ARCHITECTING! An excellent subject for discussion! Someone once told me that re-architecting is an engineer’s way of leaving his/her “mark” on a tech stack, like spraying their scent on the company. A close cousin of re-architecting is the inevitable RE-FACTORING discussion.
All engineers will say that their predecessors’ work was crap, and my theory is that if you trace the historical lineage of all products ever built, you will eventually arrive at the crappiest engineer in all of software history.
And another thing!
When you are hired into any job, you have to first make sense of your predecessor’s work, right? Work is hard.
My response to “impossible” has been the same for years. I grab a dry erase marker, hand it to the developer, pull up a chair and say, “That’s interesting. Teach me why.”
Either I have asked for anti-gravity boots and they ARE impossible (and I should stop asking for things like that) OR the developer is trying to blow smoke in my face. In which case I’ll see through that smoke during the ‘teaching’.
Now, if I could just write with the same evocative style as ‘remember the last time you had vomit in your mouth…’ (smile).
Okay, so I feel obliged to defend rearchitecting. Yes, it’s true that often it’s just an excuse not to dig through whatever was built by one’s predecessor (which is, I agree, boring), but not always.
Depending on how long a project has been underway, technology may have changed. The requirements of the project may have changed, Or (and this is less rare than you’d think), the previous architect may have had had strange or straight-out wrong ideas of how to do things and the final product of the project may have the potential to end up crippled if it isn’t rearchitected. Good project management can help stave off these potential problems, but, well, good project managers aren’t as common as you’d hope either. In a perfect world, you’d sit down to work on a project and the spec would describe exactly what the product should look like when it’s done, in every detail, and that spec would never need to be revised.
To extend your house metaphor– what if you want to remodel the bathroom, but your predecessor decided that the foundation of the house should be made of the lightest possible material that could still hold up the original bathtub installed in the house, and you want to install a fancy whirlpool tub? Do you cram that sucker in there and just kinda hope the foundation doesn’t crumble beneath its new burden?
Here’s a real-life example. We work with a Learning Management System that uses, as a back-end, raw text files on the hard drive. There are files everywhere, plaintext with all sorts of embedded markup that only the LMS itself can interpret. Fake relational database-type operations are done by reading and writing to multiple files all over the disk. This is fine when the system isn’t heavily used, but once there are more than a few hundred classes on that system, each of which has 30-50 pupils and each of which includes a bunch of quizzes and homework assignments, that flat text file architecture becomes a serious performance bottleneck. You could start throwing hardware at the problem– faster disks, fancy file systems, caching RAID controllers, and so on– but that’s only a stopgap. Eventually the system will bog down under the weight of all this disk IO and start to hinder the classes it was designed to facilitate. At this point (or ideally BEFORE this point) if you can’t easily swap out the backend and tell it to use a real database, it’s time to (gasp!) rearchitect the system.
I agree that often this is used as an excuse for engineers to not have to bother figuring out what’s going on, although, heck, I’ve seen software systems that were so complex and so poorly-documented that it was almost easier to rebuild them than to take them apart and put them back together. Again, in an ideal world this doesn’t happen, and every programmer writes copious complete and readable documentation and makes sure it’s kept up-to-date throughout the lifecycle of a project (or product), but, well. Programmers and documentation.
So, I’d say rather than just saying “Never ever tell me to re-architect!” you should qualify that– if somebody wants to rearchitect, they should have a good reason and be able to back it up with data and information on WHY they think this needs to happen. Saying that you should NEVER rearchitect, though, is just setting yourself up for shipping crappy products.
An awesome article! It containes some nice thoughts I like a lot! Good job :)
{ 1 trackback }