Live data from Hacker News

Things I've learned about writing software after 12 years

medium.com

61–70 of 122 posts

Re: Things I've learned about writing software after 12 years

#61
post #55

It's a shame the article is so egotistical, hyperbolic, and poorly edited. Also, not crediting obvious sources[1] for your punchlines smells like plagiarism. Otherwise, I really do like reading articles like this as touchstones for engineering and development. [1] http://blog.codinghorror.com/coding-for-violent-psychopaths/

thanks for the link, and for the link inside of it [1]. It expresses the core problem a lot better than the original article!

[1] http://blog.codinghorror.com/the-noble-art-of-maintenance-pr...

Re: Things I've learned about writing software after 12 years

#62
post #55

It's a shame the article is so egotistical, hyperbolic, and poorly edited. Also, not crediting obvious sources[1] for your punchlines smells like plagiarism. Otherwise, I really do like reading articles like this as touchstones for engineering and development. [1] http://blog.codinghorror.com/coding-for-violent-psychopaths/

Credit where credit is due, that was lifted nearly wholesale from codinghorror. Wonder how you do liner notes with Medium. I'm a terrible writer, so the rest of the items I've stolen or otherwise isn't to stand on the shoulders of giants like Atwood, it's to reinforce a point the best way I knew how.

I lifted all of the comments from stackoverflow, too: http://stackoverflow.com/questions/184618/what-is-the-best-c...

I'm curious where the egotistical portions were, though. I wanted to at least prefix some of the more "thou shalt" sections toward the end with a disclaimer that they're personal opinions on how I operate.

Glad you liked it, though!

Re: Things I've learned about writing software after 12 years

#63
post #19
post #8

We get the software we deserve. Apparently, people aren't ready to spend more money on performance, reliablility and security. When they buy software, they pay the price of a giant ball of mud (if they aren't expecting it to be free!) and they get a giant ball of mud. Simple. You call it insanity, I call it market, supply and demand. Of course, the perfectionists are unhappy about that (being one myself I can certain…

"We get the software we deserve." Painfully true. There are techniques for writing better software. They work. They take longer and cost more. They are not widely used outside aerospace.

Also in medical devices. IIRC FDA has standards for software writing/testing/certification.

Re: Things I've learned about writing software after 12 years

#64

There's really one issue here. Budget. You want two pairs of eyeballs on everything as you write it? Okay. Pay two guys. You want complete test coverage? Okay. Can take as long as writing the code itself. Maybe more. You want full documentation? Okay. Guy can't spend as much time on coding. You want new APIs to be included? Okay. Guy's got to read docs and try samples. Less time. What I've seen is you always end up w…

The real issue is communication, not necessarily budget, as the reason software projects I've been exposed to fail.

A project manager can only get you so far, especially if the team dynamic is rotten or even sub-par.

Management is never really the answer to me, even saying that as a coder who splits time as a manager. At the end of the day, if your team doesn't have the right dynamic -- soft skills or otherwise -- I don't think they've got a great chance of success regardless of how much budget or process you can throw at them.

Re: Things I've learned about writing software after 12 years

#65
post #8

We get the software we deserve. Apparently, people aren't ready to spend more money on performance, reliablility and security. When they buy software, they pay the price of a giant ball of mud (if they aren't expecting it to be free!) and they get a giant ball of mud. Simple. You call it insanity, I call it market, supply and demand. Of course, the perfectionists are unhappy about that (being one myself I can certain…

I guess the other thing is instability of the requirements. Something like grep or uniq are almost perfect because the use case is stable.

When I was still in training, I had the pleasure of participating on a software project to build a "web shop" for internal use at a large IT company. It was a pleasure insofar I was only a trainee and did not have to deal with the politics and all that. One day, a week before the first part of the web shop was scheduled to go live, the programmer I was working for came back from a meeting. Usually, he was pretty laid back person, very friendly and pleasure to work with/for. But when he came back from that meeting, he was mad, like, "Hulk SMASH" mad.

I asked him, as delicately as I could, what had happened.

This project we were working on, he told me, had been going on for about half a year, and during that time there had been a meeting every week, where everybody involved in the project had an opportunity to get together and review and discuss the progress of the project.

So there was this guy, who had only attended the very first of these meetings, without saying a single word. And the week before the thing is supposed to go live, he shows up again, with a long list of changes he wants to make to the application.

Needless to say, that programmer, and several other people in the room, told that guy how he had six freaking months to tell the programmers about his requirements, and the he could not possibly expect them to make all these changes a week before the application went live.

So that guy goes to the highest-ranking manager involved with the project, manages to pull some political strings, so that manager goes to this programmer's boss, that boss goes to the programmer and tells him, "I know how much it sucks, but you have to do this. I share your pain, but I, too, am powerless to refuse this request."

When building material things, it seems, houses or ships or airplanes or railraods or whatever, people do realize that you cannot tell, e.g. the construction company that you actually want a house with a circular outline rather than the rectangular one the company has been building for the last, what?, three months. Managers at car companies, I guess, do not storm into the engineers' offices a week before production of a new car starts to tell them the vehicle not only needs to be small and fuel efficient, but also needs to be able to work in antarctic climate and run on carbon dioxide instead of gasoline.

With other products - at least, that is the impression I get - people have an intuitive or explicit understanding of the limitations of the things they want to have built, and they also seem to basically understand that you cannot make drastic changes at the last minute. With software, which does exist in the tangible way that, say, a car our house does, people seem to have a much harder time understanding those limitations. I am not sure this is the entire problem with software development, but it is a big part.

Re: Things I've learned about writing software after 12 years

#66
post #40

There's really one issue here. Budget. You want two pairs of eyeballs on everything as you write it? Okay. Pay two guys. You want complete test coverage? Okay. Can take as long as writing the code itself. Maybe more. You want full documentation? Okay. Guy can't spend as much time on coding. You want new APIs to be included? Okay. Guy's got to read docs and try samples. Less time. What I've seen is you always end up w…

which is why a software project requires someone with technical knowledge doing the management, and not an MBA or "project manager" who cares only about on budget and on time at the cost of technical quality.

In a business on-time and on budget are pretty damn important. I'd argue for most software disciplines (note: I didn't say all), probably more important than technical quality.

Re: Things I've learned about writing software after 12 years

#67
post #65

Earlier quoted context omitted.

I guess the other thing is instability of the requirements. Something like grep or uniq are almost perfect because the use case is stable.

When I was still in training, I had the pleasure of participating on a software project to build a "web shop" for internal use at a large IT company. It was a pleasure insofar I was only a trainee and did not have to deal with the politics and all that. One day, a week before the first part of the web shop was scheduled to go live, the programmer I was working for came back from a meeting. Usually, he was pretty laid…

Thankfully I'm at the point in my career where, if such a thing happens, I can respond calmly and without anger that this will reset the clock on development, and that doing so is a management decision that does not reflect poorly on me or my team. If they want to do that, I can do that, but I won't take the blame for that failure.

I recognize some organizations will not accept that answer and will try to make me take the blame. Such organizations will tend to have a very poor tech department.

Re: Things I've learned about writing software after 12 years

#68
post #48

There's a sentiment in the article I see a lot that keeps coming up these days: "NASA sent a spaceship to the moon with something 100x slower than my computer, so why does it take so long to load a page"? I think it's entirely unjustified. What makes modern software engineering difficult is that it's one of the few engineering disciplines where not only are you making a Boeing 747 fly, and all the parts were made by…

> but you're also replacing the engine in flight! Could you elaborate that, using a mainstream example, please? > Also the specs on the parts are kind of spotty. ... Are you referring to the moving parts of the Internet itself? > There are layers upon layers of abstraction, and no one knows all of it. No one even knows most of it. In fact, most people don't care about any of it other than a cubic centimeter of their…

I have to disagree with you. The root problem is not that people are undisciplined, but that the problem is undefined. Take the time and effort to do things in a verifiable and provable way is useless if the solution is the wrong thing. The biggest risk in a startup is to take some investment money and build something which doesn't lead to any kind of user traction or revenue stream. That is such a big risk that it's worth writing shoddy code to chase that. If and when you find a real business idea then you can rewrite the code with the knowledge of what it needs to be genuinely useful.

But if you start with the idea that you're going to write solid code on principle then you're just throwing good money after bad.

Re: Things I've learned about writing software after 12 years

#69
post #18

The ideas behind this article are good. The author gives some guidelines that have helped them write better software. However, it makes me think about how we can make "making software" better. It seems like the best current way of going about it is to implement these zen-like self-discipline techniques that have helped the OP. What's so inherently wrong about software? Why is it so damn difficult to write software th…

"Why is it so damn difficult to write software that doesn't explode if you don't hold your tongue at the right angle?" Hubris mostly.

I don't know, it takes a certain amount of hubris to write any software at all.

Re: Things I've learned about writing software after 12 years

#70
post #40

There's really one issue here. Budget. You want two pairs of eyeballs on everything as you write it? Okay. Pay two guys. You want complete test coverage? Okay. Can take as long as writing the code itself. Maybe more. You want full documentation? Okay. Guy can't spend as much time on coding. You want new APIs to be included? Okay. Guy's got to read docs and try samples. Less time. What I've seen is you always end up w…

which is why a software project requires someone with technical knowledge doing the management, and not an MBA or "project manager" who cares only about on budget and on time at the cost of technical quality.

TL;DR - you want to hire people who can adopt and who respect both sides (business, developers)

I work as devops and my boss always says that good operation/support people are hard to find. One can be a super hero in programming, but really bad at customer service or supporting production. Similarly some ops are very horrible at coding, but they are great system administrators.

With that, I have had product owners and product managers who are really excellent at managing team and able to cope the lack of technical skill by absorbing the technical knowledge from daily standup and eventually able to work with the team to prioritize technical challenge. For example this one product owner works in big data and he couldn't ssh without me showing him, but he could go over the pipelines just enough to make me feel embarrass. Of course, if you are on a project long enough you should know how things work in general.

On the contrary I have had really senior technical people leading teams and eventually got fired for their inability to lead.

Post reply on HN