+972 52-548-6969
Horror stories from the trenches: My very first project
My first day at work, and I am but a young whippersnapper. I arrived, did the usual meet & greet with everybody (and promptly forgot their names), then I was shown to a desk, given a laptop and one of my new coworkers rummaged in a desk drawer for a while before throwing me a document. Well, I say a document, what I mean is a book.
It was couple hundred pages, and it was titled: Specs for the Ergaster module in the Heidelbergensis System. When asked what I was supposed to do with it, I was given a very simple answer: Implement.
I later found on some very interesting aspects on the spec:
- The document represented over a year and a half of work.
- The module was being developed for a client of our client.
- The module was meant to be both specific for the sub client needs and at the same time generic enough to used by other clients of our clients.
- The system that we were supposed to be a module in was currently under development and wasn’t in a position to be used by us.
Can you say 
Well, I spent close to two years working on this project. I learned a lot, from how to proof myself from upstream teams to how not to design a system. I poured a whole lot of work and effort into this.
Along the way, I also learned something very interesting about the spec. That was the first time that I actually had to reverse engineer a specification to understand what the customer actually wanted.
Two years after we handed off the module to the client, I had the chance to go to lunch with the team leader from that client, so I asked him about the module. He informed me that they still haven’t deployed to production.
I was depressed for a week afterward.
Comments
Hey, it's a free world. You can't blame anybody who wants to throw money away!
We'll I can't really top that, but I've had similar experiences.
Most of the time I find it's when non-technical people (i.e. Project managers and Business Analysts, etc) go off to gather customer requirements so that the technical experts (i.e. architects and developers) are completely shielded away from the customer. Its like good technical people could not be trusted to talk to customers and provide simple elegant solutions that best meet their requirements. The most talented analysts and UX designers I know have had at least some technical knowledge. I don't think its any coincidence that the more people use software the better they are at designing them.
This does smell like the person who created the document did not have a pragmatic eye and chose complicated solutions over simple elegant ones - I guess some people are that way inclined.
That's common story for quiet a few "enterprise" projects. No wonder, why 50% of Software projects fail :(
Sounds like a story for the Daily WTF
Actually Bunter, I'd say that is so common it'd be more suited for the DailyWYGD (Daily Wadda you gonna do?).
One thing I find funny is that where I work (and I've been doing consulting for a long time), you always meet people who have worked at the client for years, and they wonder why their company sucks so much, like it's some sort of unique characteristic that only a few companies share. Where in reality, that story could apply to every company I've ever worked for.
What's even worse is I have a colleague who tells me all these great stories about two separate companies he worked for, how they were early adopters to Agile, had full Fitness testing, amazing CI and pretty much everything that a developer could ever want...yet both those companies went out of business.
It's enough to make you shake your head and wonder, why is it that these poorly run companies hang around forever...or even become incredibly profitable, yet some well run companies go out of business. Then I remember that quality software, even for a software company, really means jack sh!t...but hey, at least it pays well. :)
@Andrew
I think you'll find it means more than that. I believe good technology and software systems that align with the business objectives is a business-enabler. Like you suggest - It is a means to an end and not the end itself. It won't mean much if you don't have a viable business model or you have a pristine technology and software development process but no idea how to market it and reach the right people. On the flip side there will probably be a lot of companies founded by good business people with poor information systems but a cash cow business model, even in these cases good Information systems would probably make the businesses run even better.
Having said that I do think qualities that most successful technology companies (with customers that love to use their software) have a very talented team and an efficient development process. Good fast, usable software that does exactly what the customer wants does not manifest itself accidentally - they usually have an expert talented team and an iterative development process. I look to Apple and Google as prime examples.
Yes, I can say "Ouch." Ouch!
I never did like the idea of throwing some huge problem at the newbie, especially without tips on, e.g., agile processes.
@Demis,
Well, I was being a bit tongue and cheek there, but I think you'd be surprised at how many companies (or at least the software department anyways) out there are run poorly.
I have have worked for the top* companies in the Natural Resources, Telecoms, Gaming and Banking industries, and the common theme between all these companies was that they weren't run well...they make/made more money than I could even fathom, but they all were run horribly. It's more common than you think.
As a newbie developer I had many ideas of how to improve software I've been working on or how to rewrite it from scratch to make it a perfect piece of engineering. But my bosses wouldn't listen to it, they just wanted to have it shipped NOW. The software was old and unmantainable, had a mixture of technologies, libraries and coding styles and was painful to look at. But customers didn't see that, they were buying it and the company was making money. And few years later the company was bought by competition and the software was ditched - so any money on reengineering it would be wasted. On the contrary, my colleagues formed a software start-up and started coding, then before releasing 1.0 they started re-engineering everything, then, before 2.0, reengineered it another time, then the guy responsible for sales resigned because he was unable to show anything finished to customers and probably you all know what happened next.
@Andrew,
maybe it is that we as a species are quite inadequate and have a huge bag of crap to carry around from evolution. We just don't know yet how to run big companies efficiently. When you enter a certain scale of things, people cannot behave anymore the way that is necessary to run a large organism efficiently.
Wow, I think I should have a long night's sleep.
Frank,
I do think there's something too that actually, I believe it's something different. In companies that aren't "tech" companies (your Googles, eBays, Amazons, etc. of this world), plenty of times the wrong person gets to the top of the IT food chain. Often it's an infrastructure person, who while they may be great at organizing new server rooms, don't know jack about software.
For example, at one company I worked for we were forbidden from unit testing...yes, forbidden, and not because any perceived time expense. No, it was because we were told that "what if the code was right, but the tests were wrong." The CTO's logic was that we'd then re-write the code (thus breaking it) to make the tests work. This was a CTO for a billion dollar corporation, one that has one many awards based on efficiency. In my career working for large corporations, this is just one of hundred examples where the wrong people are running departments.
Then again, I imagine someone from Sales, Marketing, HR, etc. would have the same stories...
I've lost count of the number of urgent projects I've worked on that never get installed by the customer.
Comment preview