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

Programmers who want to change how we code before catastrophe strikes

theatlantic.com

Post reply on HN
Print view View original

161–170 of 274 posts

Re: Programmers who want to change how we code before catastrophe strikes

#161

Post by humanrebar »

DrScump wrote: post #158
humanrebar wrote: post #116

Earlier quoted context omitted.

> Software engineers don’t understand the problem they’re trying to solve, and don’t care to. I think this is unfair. Engineers usually have great (at least qualitative though often quantitative) insight into potential, cost, and complexity. The problem tends to be in getting that feedback back into "the room where it happens", the place where budgets are set, approvals are given, disputes are resolved, and performan…

In some cases, however, ignorance on the part of the engineers (especially those with any say in the architecture of the application) of the users' needs can seriously damage the user experience for the life of the design. I face numerous examples in the sports-ticketing world all the time. For example, if you are going to a football game, what is the most important consideration to a fan? I say the most common prior…

Sure. I was just saying the cluelessness goes the other way, too, so putting it on devs is at least one sided.

Maybe a product genius can come up with better ways to sell shady stadium seats. But the technical contributors would be able to tell you that the shade-o-matic feature is layers of bad hacks that cost the company $X million a year in dev costs and astronomical security and maintenance risk since it is still running (partly) on old hand-configured Windows XP boxes using a hand-rolled UDP server library backed by an Access database. And that's for a key differentiator for the company.

Profit and success doesn't happen until both sides of the story are accounted for.

Re: Programmers who want to change how we code before catastrophe strikes

#162

Post by brfox »

nitwit005 wrote: post #108
brfox wrote: post #13

The article didn't mention it, but I think that Excel is a great example of where "the masses" have learned to do programming. It is visual and the effects of changes are immediate.

My uncle worked at a very large corporation that couldn't update to a later version of Excel because they relied on some spreadsheet to do their taxes, and some minor difference between versions broke the spreadsheet. No one could reverse engineer what the spreadsheet did. With a complex enough sheet, every cell becomes a separate function with no documentation. That's unfortunately a pattern you see with these effor…

I totally agree. I just wonder if there is some way to take that open space, visual programming which so many people do with Excel and make it more robust. Well, actually, lots of people are working on making a better spreadsheet or putting the table data into a database and making interactive plots, so maybe that's not the angle here. Maybe we can figure out how to make our IDEs more Excel-like in some ways. Not for us regular programmers, but for people who'd like to do serious programming in their subject/domain of expertise but don't want to just do it in Excel with VB.

Re: Programmers who want to change how we code before catastrophe strikes

#163

Post by KirinDave »

Periodic wrote: post #131
KirinDave wrote: post #110

The irony is the "this is all too hard write less code use more axiomatic principles and compiler assistance" is the functional programmer's call and it keeps getting shot down as 'too complex.'

Where I get the most resistance to functional programming is more in the abstractions: both that they are too complex and that people aren't already familiar with them. High-level/complex/abstract patterns are hard to understand the first time and FP seems to make those patterns easier to express. I'm surprised how much we take for granted an understanding of object-oriented coding in the industry. Any graduate with…

> I've seen people's eyes gloss over the same why when saying, "It's just a monad" as when saying "It's just an interpreter pattern".

Same. All we can do is try and change education patterns. Neither are that complex.

Re: Programmers who want to change how we code before catastrophe strikes

#164

Post by michaelchisari »

fusiongyro wrote: post #119
valuearb wrote: post #104

"For Lamport, a major reason today’s software is so full of bugs is that programmers jump straight into writing code. “Architects draw detailed plans before a brick is laid or a nail is hammered,” he wrote in an article. “But few programmers write even a rough sketch of what their programs will do before they start coding.” I almost always dive in, but I almost always write my code twice. Essentially the first round…

I feel like this is part of why Brooks says build the first one to throw away, because you're going to. People seem quite unable to imagine life with a program that doesn't exist. Building a more precise specification would be valuable if people were really able to evaluate the specification as if it were a program, but they don't seem to be able to do that. So we wind up building the whole thing to see if it's right…

> Brooks says build the first one to throw away

A great theory, but all too often, companies have a hard time scheduling time for a rewrite, and the hacked-together rough-prototype code gets pushed into production in perpetuity.

Re: Programmers who want to change how we code before catastrophe strikes

#165

Post by eggy »

hwayne wrote: post #101
insertnickname wrote: post #48

Earlier quoted context omitted.

It'll just encourage companies to rewrite all their software as one line of Perl.

My J skills will finally be worth something!

No kidding! I love J, and I find it very easy to troubleshoot, since it is all within a few lines or a page. Forth is like that too.

Re: Programmers who want to change how we code before catastrophe strikes

#166

Post by humanrebar »

milkytron wrote: post #160
gregmac wrote: post #33

Earlier quoted context omitted.

> for another developer (who may not exist) You, 6 months from now (or whenever you stop touching this code base), are effectively "another developer". New developers don't seem to really grasp this until the first time they have to maintain their own old code. I don't think it really hits home until the first time you experience: "What is this? Who wrote this garbage??" runs git blame "..oh, crap."

This is why I usually throw in comments with myself as the recipient for understanding where complexity exists. I've heard people debate over whether comments should be in well written code, including some that argued comments should never be used at all. Party A: Code should be easily understandable so that comments aren't necessary. Party B: Comments should exist where complexity exists to save a developer's time w…

Generally the best comments are to describe "why" (sometimes "how") more than "what".

Of course, good writers know their audience. If that code is somehow strange in its organizational context, a few "what" comments and links to references, documentation, and/or tutorials can be great.

Re: Programmers who want to change how we code before catastrophe strikes

#167

Post by walshemj »

Periodic wrote: post #135
Animats wrote: post #28

Earlier quoted context omitted.

In the history of the Bell System, no electromechanical exchange was ever totally down for more than half an hour for any reason other than an natural disaster.

The reason cited seems much more a case of moving call-management into a high-level software system that didn't have the same sort of rigor that telecom systems traditionally have. Maybe it did and someone missed this? It's hard to know. In short it feels a lot more like a management failure than a failure of software.

Probably a lowest cost bidder and not helped by the US devolved government if this had happened in say the UK the papers would have a field day and the government would force the telcos to fix it stat!

Re: Programmers who want to change how we code before catastrophe strikes

#168

Post by emodendroket »

vikascoder wrote: post #150
emodendroket wrote: post #132

Earlier quoted context omitted.

So basically all our problems will go away if we return to UML and requirements documentation that's hundreds of pages long and edited for ages before anyone writes any code.

Thats how most Medical Device software is written :)

Fair enough but it's hardly a panacea. I think it likely does work better with something like that where the requirements are truly well understood, though. Most of this "agile" stuff is working around people not being able to tell you what the hell they want.

Re: Programmers who want to change how we code before catastrophe strikes

#169

Post by sidlls »

emodendroket wrote: post #132
valuearb wrote: post #104

"For Lamport, a major reason today’s software is so full of bugs is that programmers jump straight into writing code. “Architects draw detailed plans before a brick is laid or a nail is hammered,” he wrote in an article. “But few programmers write even a rough sketch of what their programs will do before they start coding.” I almost always dive in, but I almost always write my code twice. Essentially the first round…

So basically all our problems will go away if we return to UML and requirements documentation that's hundreds of pages long and edited for ages before anyone writes any code.

That sort of development practice has a much closer relation to engineering than current practice does: it's just that it's extremes are on the other end of that one.

Re: Programmers who want to change how we code before catastrophe strikes

#170

Post by chrisweekly »

tmnvix wrote: post #3

> "Programmers were like chess players trying to play with a blindfold on—so much of their mental energy is spent just trying to picture where the pieces are that there’s hardly any left over to think about the game itself." This is an insightful description of the biggest mental challenge I face when programming.

+1. Same experience.
Post reply on HN