The shittiest project I ever worked on • Hacker News Board

Re: The shittiest project I ever worked on

#141

Post by GFischer » Wed, Sep 25, 2013, 2:33 PM UTC

josephagoss wrote: post #48

paulhauggis wrote: post #40

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. I worked there for about a week before I quit in frustration.

How can someone suggest auto convert into another language like that? In the long run it would be cheaper rebuilding the entire thing.

There are some (very few) cases where it makes business sense.

For example, the company I work for has software developed in a legacy language with no support (Forte 4GL).

There are companies that offer Forte to Java migration, it would have been worth it because of better tools and support (even if the code was the same crap as usual :) ).

Re: The shittiest project I ever worked on

#142

Post by nmcfarl » Wed, Sep 25, 2013, 2:35 PM UTC

josephagoss wrote: post #48

paulhauggis wrote: post #40

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. I worked there for about a week before I quit in frustration.

How can someone suggest auto convert into another language like that? In the long run it would be cheaper rebuilding the entire thing.

I've actually been involved in at least three projects to do precisely that. And mostly they worked fine.

In two of the three cases I was converting between "the same language" but different incompatible versions of it and the original code bases had strict style guides. At the end of it everything worked brilliantly, and the code was just as maintainable as it was before the conversion.

In the third case was an full lexer/parser built out to compile VBScript down to JavaScript. The resulting code was not readable or maintainable but it did run and that satisfied the needs of the project.

In my experience is that language conversion projects are gnarly, and depend heavily on style guides and accurate specifications for the languages to produce good output. But these are not doomed enterprises from the start and in the end it's the quality of your convertering code that determines the success of the project.

Re: The shittiest project I ever worked on

#143

Post by akg_67 » Wed, Sep 25, 2013, 2:36 PM UTC

kabouseng wrote: post #96

akg_67 wrote: post #66

Earlier quoted context omitted.

As a former chemical engineer, I agree with your gf's classmates. In late 90s, I was working on an advanced chemical manufacturing process control project with a team of software developers. I found out they were getting paid twice as much as me and they were half as productive as me (they knew nothing about manufacturing, chemicals and process control) and I was twice as stressed as them. The best decision I made wa…

Or you could have moved to the petrochemical industry, where you would have been paid more than any software engineer anywhere...

Actually, it was petrochemical company, one of the largest. And no, petrochemical industry doesn't pay much more than software profession.

Comparing with my friends who are still doing ChE jobs, If I was still in petrochemical, I most probably be getting paid little less than what I am being paid now, but working much more harder, longer and more stressed.

Re: The shittiest project I ever worked on

#144

Post by jerf » Wed, Sep 25, 2013, 2:43 PM UTC

floobynewb wrote: post #124

tripzilch wrote: post #116

Earlier quoted context omitted.

That's not actually how artificial neural networks in pattern recognition tasks really work. Once you learn and understand the learning algorithms, you will experience this Wizard of Oz moment, you see how the trick's done and it's not quite as impressive as you hoped. This is confirmed by the fact that it exactly matches the limitations of a typical neural net you've established experimentally. The tasks that are wi…

I think this is wrong. Take for instance the task of classifying images. You can train a RBN with backprop (after contrastive divergence alg) to correctly classify images. In the process it has automagically determined properties of the image which allow it to perform the classification. These properties are combinations of pixel elements. So it has in effect determined how to solve a problem without your input. In a…

"In the process it has automagically determined properties of the image which allow it to perform the classification."

(Emphasis mine.) But that's the point; it may be "auto", but if you understand how NNs work it's not magic. It's not even all that hard to understand (considered broadly), and once you understand how they work it is, for instance, easy to construct cases they fall flat on....

"So it has in effect determined how to solve a problem without your input."

... and it's less "auto" than you think. It figured out how to solve a problem based on your input of sample cases. And there's a certain amount of art involved in selecting and herding your sample cases, so regrettably you can't discard this part, either. Just flinging everything you've got at the NN is not going to produce good results.

If you don't understand NNs, you are unlikely to get good results by just flinging data at them; if you do get good results, it's probably because you have a problem that could have equally well been solved by even simpler techniques. They're really not magic.

Re: The shittiest project I ever worked on

#145

Post by Sami_Lehtinen » Wed, Sep 25, 2013, 3:08 PM UTC

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.

Re: The shittiest project I ever worked on

#146

Post by pessimizer » Wed, Sep 25, 2013, 3:37 PM UTC

thekingshorses wrote: post #19

nekopa wrote: post #11

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. (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)

Just say we will load data(phone number) using AJAX in JSON format and everyone will be happy. Page is static. JSON is a static file with a phone number. And use jQuery to load the JSON file.

...into Angular.

Re: The shittiest project I ever worked on

#147

Post by zenshade » Wed, Sep 25, 2013, 3:41 PM UTC

shailesh wrote: post #69

redact207 wrote: post #12

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. I think that's the key difference to an experienced dev/BA. One who can actually sit with…

Kind of agree with you and OP, so let me add to the discussion with the caveat that YMMV etc. Some of these points may overlap with comments by fellow HNers in these threads. In any organization as a prospective customer, there are three forces at work that matter to a consultant: users, decision makers and finance folks. Ideally, the decision makers appoint a dedicated person (or team) who mediates users and finance…

I rarely comment here, but your excellent post deserves to be recognized. I'm someone who has thought a good deal about starting a consulting company but never managed to convince myself the risk/reward numbers would work for my life situation. Your richly detailed and honest perspective is much appreciated. Thank you.

Re: The shittiest project I ever worked on

#148

Post by boomlinde » Wed, Sep 25, 2013, 3:44 PM UTC

jerf wrote: post #144

floobynewb wrote: post #124

Earlier quoted context omitted.

I think this is wrong. Take for instance the task of classifying images. You can train a RBN with backprop (after contrastive divergence alg) to correctly classify images. In the process it has automagically determined properties of the image which allow it to perform the classification. These properties are combinations of pixel elements. So it has in effect determined how to solve a problem without your input. In a…

"In the process it has automagically determined properties of the image which allow it to perform the classification." (Emphasis mine.) But that's the point; it may be "auto", but if you understand how NNs work it's not magic . It's not even all that hard to understand (considered broadly), and once you understand how they work it is, for instance, easy to construct cases they fall flat on.... "So it has in effect de…

Understanding NNs is not the same as understanding "how they do it". You may have a good understanding of how the algorithms work, but after training your moderately sized network to do what it does, it's not very easy to know what _exactly_ it does to solve your problem.

I think that's what chii was trying to point out; not to say that devising them and training them is incomprehensible.

Re: The shittiest project I ever worked on

#149

Post by misterjangles » Wed, Sep 25, 2013, 3:49 PM UTC

fibbery wrote: post #62

misterjangles wrote: post #44

Earlier quoted context omitted.

My sarcasm detector is showing erratic results from your post. AJAX was 3 years from being invented and John Resig was about 10 years old in 1995. Perhaps a whooshing sound should be made though, if I didn't get the joke..?!

You missed "If you removed the dates from this story.." in the parent comment.

Ah, thanks!

Re: The shittiest project I ever worked on

#150

Post by briancpotter » Wed, Sep 25, 2013, 3:55 PM UTC

AndyKelley wrote: post #51

adamconroy wrote: post #50

Earlier quoted context omitted.

Sorry if it reduces self-esteem, but we (software developers) are not engineers. I've been brainwashed for many years by my brother, who is a Phd civil engineer, that professions that hijack the term engineer are kidding themselves. I know it sounds cool, and my current title is 'Senior Software Engineer', but it is all a scam.

I'm not convinced. Care to make a case?

The degree of responsibility is vastly different. Engineers are licensed, and can (and often are) sued for professional negligence. Failing to do your job adequately means you'll be stripped of your license and prevented from practicing engineering.