Although it's a fun read, it's a classic example of diving into coding without giving a project it's due diligence. There's nothing that's derailed my projects more consistently when I started out as not understanding the user's needs. They'll never tell you what they want, only what they don't want after you deliver something.<p>I think that's the key difference to an experienced dev/BA. One who can actually sit with the stakeholders and build the system on paper and go through each of the problems as the diagrams connect. What you end up with is the stated requirements (tip) and the unstated assumptions (iceberg).<p>These types of projects are easily spotted as they're often called "quick" or "easy", which in layman's means no one's really thought about it yet.
For those who don't know about the author of this post. His name is Mark Jason Dominus, the author of one the most awesome programming book that one can ever read.<p>Higher Order Perl, is available for free download. If you read it you will see some amazing insights into programming techniques most people would have never heard of encountered in MegaCorp jobs. You will also grow a great appreciation for Perl in general and understand how it can be an amazing language of choice for a wide variety of problems.
>Prudential didn't need an affiliate locator application. They needed a static HTML page that told people to call the number.<p>They needed a competitor.
> In 1995 I quit my regular job as senior web engineer<p>You had the job title "senior web engineer" when the web was 4 years old. That's pretty cool.
I'm surprised nobody, not even the author, has said that the program was useful anyway. But instead of publishing it in the web, it should have been used by the toll-free number operators.
I never cease to be amazed that the more things change, the more they stay the same. If you removed the dates from this story, you'd be hard pressed to fix when this happened.<p>(Except the static HTML idea is a bit of a give away, no web developer would ever dare suggest a static page in our brave new world of Web X.0)
> <i>These days I would handle this easily; after the first or second iteration I would explain the situation: I had based my estimate on certain expectations of how much work would be required; I had not expected to clean up dirty data in eight different formats; they had the choice of delivering clean data in the same format as before, renegotiating the fee, or finding someone else to do the project.</i><p>Great advice for dealing with issues we did not consider in our estimate.<p>Had he charged hourly instead of a fixed price, would this project have been less shitty?<p>Edit: Fixed grammar. Thanks b0z0. :)
Sounds about right.<p>I worked at Prudential about 10 years ago, as a FTE. Our small division mainly ran on a bunch of custom Access reporting applications. It wasn't quite cutting it, because Access, so it was decided that we would build a portal on the company's intranet. The only problem was that we, as accidental web developers, were not allowed to run development web servers on our dev machines, because they were locked down by corporate. We had to use an extra PC that, by some miracle, had IIS, and develop against that remotely. Good times.
The title reminds me of the shittiest software job/project I ever worked on- short and sweet: Got hired off craigslist. It was all php. Their main competitor was "the spreadsheet". Worked directly next to a cold caller that repeated the same phrase over and over again, fake laugh and all. They were all from the same church group and tried to convert me multiple times. Paid minimum wage.<p>In addition to being funny in retrospect, it was a good lesson to me to learn that no matter how shitty your current situation, you can always improve it.
The punch line here is great, but even if the specs necessitated something more than a static page, then it'd still be a hard job.<p>If the most critical part of a data heavy project is speccing it out, I'd say the next most important part is the data munging process...and sadly, both of these things are the most overlooked.
I'm sure this is the very tough first lesson any new consultant with limited experience would learn. The summary is that the specs are incredibly important, they should be expensive to produce and they should protect you and your client.
That's not bad at all, it's sounds more like business as usual. I think it's my regular workday.
Btw. Did the customer require extensive documentation, escrow, you to fix their data when they can't get it done (like invalid post area codes linked to wrong addresses, fixing post number / city information based on post area code) etc or looking it up based on street adress or so. Been there, done that. Did you spend several weeks in meetings where they can't decide how their stuff works, and you'll just keep wondering if they'll ever decide what they actually want etc. Of course they're going to completely change that week later etc. They don't have a clue how things should technically work, or even what the actuall business process is. Because they have bought an integration, everything must just automatically work, right? We need to know what females in age range 20-25 have bought during last month. Err, but we don't record customer age or sex? Well, but our management team needs that information. It's sure alarm sign, that they want to know how much "this" project will cost, but nobody really knows what "this" is. Also it's needs to be completed by end of the month. I have declined so many projects, and clearly told customers why I'm not going to do anything for them at all. Unless they accept it as "agile" project, with unlimited budget. Then I'll promise them that I'll personally see that it gets done, but it's going to be expensive. - 15 years of ERP/POS/BI/CRM integration programming & consulting.
I am working on quite a tedious project right now. It involves 10 years old, quite extensive, Visual Basic 6 programs. No source control was used. In our company it is practice to hire interns for 3-month periods to work on production software. A mix of programming styles can be found in this project. Some functions return 0 when they fail. Others return 1. Or -1. Or False. Or "False". I love it!
"In 1995 I quit my regular job as senior web engineer for Time-Warner and became a consultant developing interactive content for the World-Wide Web, which was still a pretty new thing at the time."<p>I am confused the person stated that they were a senior web engineer but quit to work on a new thing the WWW. How can you be a senior web engineer for something brand new?<p>Just nitpicking...
One of the best examples of consultant failure i've ever seen. Clearly an example for<p>- not enough questions asked
- not listened to the customer<p>Do not ever start building something or proposing a solution if you don't understand the customers problem deeply enough.
I can highly recommend Flawless Consulting by Peter Block.
He covers all these issues and many others. Self awareness is critical to success. If you are inexperienced you need to be able to recognize/acknowledge your inexperience. Then read everything available on the subject and interview every expert you can identify. Clint Eastwood said it best, "A man's got to know his limitations". <a href="http://www.youtube.com/watch?v=_VrFV5r8cs0" rel="nofollow">http://www.youtube.com/watch?v=_VrFV5r8cs0</a>
Fascinating! As somebody who is starting to do freelance work a story like this is not only an interesting read but provides insight on what to avoid and when to speak up as I start freelancing.
The shittiest project that I worked is just finished where we are not allowed to write any test cases cause we don't have time. I just can't believe that I finished fairly big project without writing a single test case. I hate my company, my role and managers, sales people who negotiate tight deadlines. Over all don't work for any consulting companies out there. They care less of the code quality. They just want money and no ethics.<p>My next job will be a product based company.
Consider the price you paid to learn a key life lesson which will pay for itself multiple times over. If you learn from the situation, you have not failed.
This is why:<p>1. You should spend more time designing (away from the computer) so that you find a _problem_ and then come up with a reasonable solution. Instead of putting together a list of features. (see Rich Hickey's talk "Hammock-driven development").<p>2. Think of the sum you're going to charge for your consulting and then multiply it by 4 and charge that because you have to take risk and other factors into account.
The shittiest project? Hmm...if he got paid, not sure I'd classify it as such. A waste of time because of business getting in the way of potential efficiency that they perceived they wanted? Yes.<p>Also, let's not forget that this was 1995 and most big businesses weren't really fully aware of the potential of the internet and the disruption on standard business models that was going to ensue...
Sounds like poor contract negotiation more than anything. Fixed quotes are very tricky things to navigate. I simply don't go there. If the client insists then I try to negotiate a fixed budget, then when the budget us running dry they can extend the budget or reduce scope. If they don't agree to that I walk.
Interesting read. However, I helped build a web based system for the management of a bowel cancer screening programme. Considering what would be sent back on the testkits and processed into the system... it's the shittiest project I've ever worked on, but not for the same reasons :P
The reason the fee was there was to pay for the 0800 thing.<p>Some executive rightly saw that paying you to render that useless would free them of that service and the need for the fee (which i bet was not turning a profit)<p>But, since big companies run on cargo cult... that happened.
If that's the shittiest project you ever worked on then you're a lucky guy. User's will use a software project for all sorts of political purposes that have nothing to do with you and it does nothing but f up the process.
This is how life insurance companies operate on a daily basis. OP had a pretty shitty deal but he should count his lucky stars that he didn't have to interact with actuaries, who would have multiplied the same problems ten-fold.
wow! I am jealous. If that is the shittiest project he ever worked on, he really has not too much to complain about.<p>Add to this that this was back in 1995. Companies had no clue what the internet was nor what they wanted to do with it, so this kind of clueless behaviour what the customer wanted was pretty much standard for most companies up to at least 1998 - 1999.<p>The guy has either been tremendously lucky, or he has not worked in too many different projects / companies for the last 18 years....
This got infinitely more readable when I loaded it into Pocket and let Pocket do its formatting on it. Adjustable font size and a more reasonable line width...
I could see why development service team always want to get more and more information about a project. Open it more, then you get better return. Fun reading.
The shittiest project I ever worked on was a php project that was converted from another language (I don't remember which one). This doesn't sound bad, except they used software to automatically convert it. The PHP code had no comments, minimal white space, and the variables were all hex. My job was to fix bugs.<p>I worked there for about a week before I quit in frustration.