Comment a cautionary tale (Score 2, Insightful) 321
at my last company, i was part of the new R&D department intended to make us no longer reliant on 3rd party contractors and consultants (which had been going poorly for us). we had multiple product lines with no coherence between any names and numbers. we had a product retroactively named Phase 2, an unrelated product retroactively named Phase 3, and its successor named Phase 3 Version 3, all with what amounted to point releases, without any identified version numbers or names. it was often just difficult to tell what we were talking about.
so when we started working on our own stuff, we did better. we went "major.minor (build)". the head of marketing made a compelling case for being able to decide what was "major" and what was "minor" as far as our clients were concerned, and we thought that was fine. when we were on, say, version 2, we'd have a roadmap for the next several feature/fix packages and say "we think this bundle is version 2.1, this next one is 3.0, then 3.1, 3.2, 4.0". we went 2-5 feature/fix bundles into the future. marketing would come back and say something like "we really need a major-number release earlier than some trade show; make that 3.1, 4.0, and 4.1". some of the engineers were unhappy with this, but i think that's mostly because they discount the validity of marketing and psychology in commercial enterprises generally. in reality, it worked fine.
for about 4 months. then the marketing guys decided to start changing things. frequently. they'd discover some other show they needed to get to, or decide one was less important, or a customer would tell them (stupidly) "we're going to wait for the next major version" or "we don't trust
the biggest problem for engineering was that, again, it was hard to know what we're talking about. when we met to discuss the feature set to put in 3.2, or the planning for 4.0, which 3.2 was that? no good. so we gave up, told marketing that they could simply have the version number all to themselves, and we came up with a unique identifier series to use ourselves: each feature/fix bundle got a volcano name. we could talk about the features in Koko, or decide Krakatoa was too big and break it into Deccan Traps and Viti. we got everyone - including the head of marketing and the CEO - to agree that these were internal-only, engineering-defined designations for feature sets, not tied to published version numbers or whatnot. marketing got nice numbers to show clients, we got reliable, unambiguous identifiers. worked great.
for a little under two years. then we had a review release for the "Kick 'em Jenny" release, where the head of marketing (yes, same one) "asked" us to change the name. R&D had been using it for about six months, so this was reintroducing the same problem we'd invented them to fight off, so, as the engineering manager on the project, i wasn't happy to see this happening, and asked why.
"well," he says, "we can't very well tell that to clients."
"er, right. that's half the point. these are engineering names, remember?" i responded.
"yes, well, the clients like to know the names. we've been telling them all the earlier ones."
(elided arguing and frustration on all sides)
"okay, okay." i said. "a month or two ago, actually, they discovered a near neighbor to Kick 'em Jenny. i guess we could use that as the name, instead."
"that's fine. what's the new name?" he asked, taking the bait.
"Kick 'em Jack."
then the CEO got involved in the conversation, suggested we come back to it later but that the name would probably have to change to something "presentable", and we moved on. except the feature bundle never got out the door under any name, and the smaller ones to replace it fell flat, and the project progressively fell apart until the company was bought by a competitor. i can't prove a relationship, of course; just sayin'.
i don't really know what lesson to learn here other than "never give marketing any control or power". they don't know how to respect other interests and believe themselves to be more important than they are. keep someone with an engineering mindset overseeing all aspects of technical products.