Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The shittiest project I ever worked on

blog.plover.com

Post reply on HN
Print view View original

161–170 of 187 posts

Re: The shittiest project I ever worked on

#161

Post by consultant23522 »

Daniel_Newby wrote: post #73
adamconroy wrote: post #64

Earlier quoted context omitted.

Well it is really just semantics, so there is no right or wrong, and anyone can define what particular words mean to them. But there are a couple of things that make me personally think software engineering is a misnomer. Firstly, traditional engineering disciplines are generally pretty black and white. It is applied maths and science. If you build a bridge, you can use physics and maths to pretty much prove that it…

The distinctions you are making are mere tendencies. Automotive engineering, for instance, requires everything on your list of software development traits—in spades. I would say that the essence of engineering is a devotion to verifying that the design works like you think it works. Software development often lacks this devotion, but when it is there it is entirely proper to call it software engineering.

I think the big difference is that the civil engineer doesn't actually lay the cement himself, but the software engineer does. This has a lot of ramifications about how each approaches the problems and sees themselves in context.

Re: The shittiest project I ever worked on

#162

Post by drblast »

n1ghtmare_ wrote: post #47
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.

Well, I once worked on a Web App that was written in PL/SQL, that produced HTML. Every variable was named v1, v378, vT31 (yeah no order), and the whole app was in 3 procedures each 80,000 lines of code, AWFUL AWFUL CODE. Honestly the horrors. Stuff like: if condition do x else do x I worked on it for a month and it felt like years.

That's nothing. I had to fix someone else's program once. It was written in PERL.

Re: The shittiest project I ever worked on

#163

Post by eitally »

cygwin98 wrote: post #136
eitally wrote: post #113

Earlier quoted context omitted.

The flip side of this is that when stakeholders/customers don't know what they really want or need, you can labor in the "requirements phase" for months. My team spent 900 hours last year just getting a functional spec and high level SRS together for a project that hasn't happened yet. Why hasn't it happened? Because at the end of the 900 hours, we presented our estimate (about 1100hrs) to the customer and he balked…

If you billed those 900 hours for doing RFP for the customer, it doesn't sound too bad.

We couldn't bill them -- it was another SG&A department and we (IT) don't bill them for our work.

Re: The shittiest project I ever worked on

#164

Post by jakejake »

brianmcconnell wrote: post #83
misterjangles wrote: post #41

Earlier quoted context omitted.

The tricky part is often convincing a client that pre-planning is a necessary part if the process and, though it is billable time, will ultimately save money. Many client don't appreciate that programming is not just writing code. Also you can wind up meeting and planning yourself right out of a gig sometimes - which is fine if the gig wasn't truly necessary. But can be bad for your business if you spend hundreds of…

The trick then is to get clients who know they just want to "have it taken care of", and have much higher billing suppliers (IP lawyers, pharma experts, etc). In that case, they don't really think twice about paying for process in advance of coding. Pharma is a good example. Being a contract resource for a software company, where management tends to think everything related to software/IT is "easy", is a guaranteed s…

I ran a small software consulting business for about 5 years and I agree 100% with you. Business was stressful for the first few years until I narrowed down my client base to only those in the first category. I never did land a huge, corporate client, but I did have several smaller sized companies with a never-ending list of things to do and around X number of dollars budgeted each month.

Re: The shittiest project I ever worked on

#165

Post by bonemachine »

akg_67 wrote: post #66
nostrademons wrote: post #55

Earlier quoted context omitted.

It's kinda ironic, but my girlfriend's business school classmates (most of whom are electrical, mechanical, or chemical engineers) seem to think that software engineers are at the top of the engineering totem pole. Something about being the only engineering subdiscipline that's paid what they're worth. If it's a scam, it seems to be working.

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…

Our salaries aren't a scam, per se. Just a reflection of a market equilibrium condition driven by classic rent-seeking dynamics:

  https://en.wikipedia.org/wiki/Rent-seeking
which don't apply as much to lower-demand professional categories.

Which isn't to say we aren't worth it; I'd like to think we are. Just that we often delude ourselves into thinking that our salary differential is linearly correlated with the economic "value" we generate. It isn't.

Or rather: the "value" of an engineer is a lot like the value of an apartment in a high-rent neighborhood: the price holds in the market because, well, you have to have it, and at (almost) any cost in order to do all the other stuff you need to do, like get around the city and be close to your job.

You also have to have access to food and safe drinking water -- even much more than you need a convenient or semi-stylish apartment. The priority for these isn't just a bit higher: it's categorically higher. Yet their base cost (i.e. the cost to obtain them at nominally satisfactory level) is an order of magnitude less than the cost of your rent.

The distinguishing factor between the two classes of goods is, of course, scarcity. That is why your rent is damn high.[1] And that's why an average software developer can earn twice as much as a decent chemical engineer, and an ungodly multiple of what a great public school teacher makes.

[1] Along with the fact that high-demand apartments -- like high-demand engineers -- are also, arguably, Veblen goods in some markets:

   https://en.wikipedia.org/wiki/Veblen_good

Re: The shittiest project I ever worked on

#166

Post by lifeisstillgood »

weland wrote: post #107
lifeisstillgood wrote: post #85

Earlier quoted context omitted.

and the success rate? and value delivered?

How dare you bring technical excellence as an argument? Don't you know this is about money, not performance? Jeez, get an MBA.

that took a minute to process !

cheers

Re: The shittiest project I ever worked on

#167

Post by GlennS »

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.

Code generation isn't particularly hard as long as your source language or API is well specified. The problems come after.

One shot code generation is usually fine (make it, run it, throw it away).

Similarly, if the target language is never going to be read or edited by a human then you should avoid most issues.

Re: The shittiest project I ever worked on

#168

Post by roel_v »

eitally wrote: post #163
cygwin98 wrote: post #136

Earlier quoted context omitted.

If you billed those 900 hours for doing RFP for the customer, it doesn't sound too bad.

We couldn't bill them -- it was another SG&A department and we (IT) don't bill them for our work.

How can you spend 900 hours without someone taking responsibility for it? After 4, you say 'give me a project nr or talk to my boss.' I'd be pissed too if my staff spend 900 hours on a dud without approval or accountability.

Re: The shittiest project I ever worked on

#170

Post by huherto »

greenyoda wrote: post #34
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…

"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." Reminds me of an old saying: "If you don't know how to do it, you don't know how to do it on a computer."

Paraphrasing: "You don't know how to do something until you can write a program to do it"
Post reply on HN