Suffering-oriented programming • Hacker News Board

Re: Suffering-oriented programming

#61

Post by bwarp » Tue, Feb 07, 2012, 11:16 AM UTC

tim_h wrote: post #17

bwarp wrote: post #9

The art of thinking about a problem appears to be lost. What happened to getting it fast, beautiful and possible first time by thinking about it? I come from an engineering background and "right" is the only way to do it.

In software engineering the "thinking beforehand" approach is probably riskier than the "think as you go" approach. For example, often the requirements aren't well-defined when the project starts. Contrast this with physical-stuff engineering (which I think is what you're referring to by saying "engineering background"), where the requirements tend to be better-defined and the cost of experimentation/refactoring is a…

Well electrical engineering turned out to be 50% software (much to my dismay) so I'd say it was right between tangible and non-tangible engineering.

Re: Suffering-oriented programming

#62

Post by stavros » Tue, Feb 07, 2012, 11:41 AM UTC

bwarp wrote: post #58

revorad wrote: post #13

Earlier quoted context omitted.

I'd love to hear some examples where you got it fast, beautiful and possible the first time.

One example where "engineering" versus "agile" paid off: In 04/05, I single-handedly wrote a large Windows Mobile (.Net CF) and SOA platform for managing proof of delivery across 5000 devices which used server-push messaging over semi-persistent GPRS links. This required about 6 months of work after 3 months of R&D. It was delivered on time, with zero defects, worked perfectly on low bandwidth connections and require…

Where's the payoff? All I see is a system that had to work first time, so "agile" wasn't even an option. If there were an auto-update mechanism to get everyone on the latest version, it seems to me that you might have delivered months earlier and polished it over time.

Re: Suffering-oriented programming

#63

Post by bwarp » Tue, Feb 07, 2012, 3:19 PM UTC

stavros wrote: post #62

bwarp wrote: post #58

Earlier quoted context omitted.

One example where "engineering" versus "agile" paid off: In 04/05, I single-handedly wrote a large Windows Mobile (.Net CF) and SOA platform for managing proof of delivery across 5000 devices which used server-push messaging over semi-persistent GPRS links. This required about 6 months of work after 3 months of R&D. It was delivered on time, with zero defects, worked perfectly on low bandwidth connections and require…

Where's the payoff? All I see is a system that had to work first time, so "agile" wasn't even an option. If there were an auto-update mechanism to get everyone on the latest version, it seems to me that you might have delivered months earlier and polished it over time.

It didn't have to work first time. People expected it to work first time and the expectation was fulfilled. Would you deliver a stinking turd first time and spend 6 months fixing it? That appears to be the way people want to work these days but believe me the customers are fucked off with it. The entire industry is getting a bad rep due to this laziness.

Re: Suffering-oriented programming

#64

Post by StavrosK » Tue, Feb 07, 2012, 5:03 PM UTC

bwarp wrote: post #63

stavros wrote: post #62

Earlier quoted context omitted.

Where's the payoff? All I see is a system that had to work first time, so "agile" wasn't even an option. If there were an auto-update mechanism to get everyone on the latest version, it seems to me that you might have delivered months earlier and polished it over time.

It didn't have to work first time. People expected it to work first time and the expectation was fulfilled. Would you deliver a stinking turd first time and spend 6 months fixing it? That appears to be the way people want to work these days but believe me the customers are fucked off with it. The entire industry is getting a bad rep due to this laziness.

You're making bad assumptions. You can either deliver a "stinking turd" in a month and spend 5 months fixing it, or spend 6 months developing and deliver the whole thing in one go.