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

Things I've learned about writing software after 12 years

medium.com

Post reply on HN
Print view View original

51–60 of 122 posts

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

#51

Post by will_work4tears »

marssaxman wrote: post #21
bprater wrote: post #17

Earlier quoted context omitted.

12 years is the middle years for a career programmer. Enough to know what patterns aren't serving you, and enough to know that there is still a bunch to learn.

Middle years!? How long are these "middle years" supposed to last? I'm 22 years into my career and there's no way I've hit the mid point yet. It still feels like a joke to have a job title with the word "senior" in it.

How long have you been programming full time though? I find too many people on HN are 25 and count "15 years experience" because they started programming at 10. It's just not the same thing, especially when most people only count professional experience (and full time at that). 15 years of programming experience < 10 years full time experience in an enterprise or startup environment.

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

#52

Post by jordanpg »

gibrown wrote: post #22
jordanpg wrote: post #7

Excellent piece of writing. Very funny at times, witty like a satirical novelist. Particularly enjoyed the anecdotes from NASA and the author's conveying of the powerful emotional context of high stakes programming. I pine for a golden, future age of programming where documentation is as he describes. > This image brought to you by preventable catastrophe, budget overruns, political wrangling, infighting, incalculabl…

"dismal" - that's an absurd word to apply to an organization that has successfully enabled humanity to explore the solar system over the course of a short 50 years. There is plenty to Monday-morning quarterback, but "dismal" is not the word I would ever use.

You're reading me wrong. Dismal means sad, and the caption is meant to be wry or ironic.

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

#53

Post by wvenable »

Kenji wrote: 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've only recently started working for larger more corporate-type firms and it's absolutely amazing how much they pay for giant ball of mud software. Astronomical amounts and then on top of that there are maintenance fees, support fees, upgrade fees. It's absolutely amazing and frightening the money being spent.

So I think the problem isn't money; the real problem is there just isn't enough software! We have a software deficit. With software being a critical part of nearly every business in the world, there is huge demand but massively insufficient supply. In my industry, there are only two big software providers and a handful of smaller ones. And it's a huge industry in both money and sheer size. But they literally cannot buy anything but big balls of mud.

People are paying big money and small money for whatever software they can get. And that natural consequence is that performance, reliability, and security are hit or miss.

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

#54

Post by mturmon »

RussianCow wrote: post #30
mrits wrote: post #3

Earlier quoted context omitted.

I stopped at about 5 words in with the oddly placed comma and capitalization.

You stop reading things as soon as you encounter an "oddly placed comma"?

Like gcc, one misplaced comma and the whole thing might as well be rubbish.

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

#55

Post by bch »

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/

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

#56

Post by d--b »

lordnacho wrote: post #27

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…

I think the main issue the OP is trying to describe is not the tradeoff between cost and quality. I believe this is well understood. However the problem that is not well understood by non-developers is the cost of change. Maintaining software is _extremely_ costly, and people simply do not get that.

While everyone understands that maintaining a physical infrastructure like a highway involves a large amount of energy (create an alternative road to redirect the traffic, fix the road, destroy the alternative road), it is not true of software. Because what happens in the code is not obvious, clients and managers have no idea of the effort that would be required to change an existing piece of software without disrupting the current flow of operations.

Let's take a more practical example: The boss asks you to create a datatable in a database to store client information. And according to the first specs, each client has one address, so you go on and create a table that contains client id / client name / client address. Everything works fine, great! Now, you do your demo, and suddenly the boss tells you: hey I've got 2 addresses, can I have my 2 addresses stored in the system? You have then 3 choices:

1. Tell your boss: no there's only 1 address in the system 2. Tell your boss: ok I can put 2 addresses, but then it means I have to split the user table and create an indirection. So I have to rewrite the whole address read/write layer. 3. Tell your boss: sure I can do it. What I'll do is take my first design, add 3 or 4 'additional' addresses to my table (who's got 3 or 4 addresses anyway?) and I'll just have some minimal changes to make to my code.

In most cases, if you're the developer, you'll opt for option 3. You may think in the back of your head that this is disgusting and that you'll change it later, but any of the other two options will make you look pretty bad.

Later on, the boss asks you, hey you know what would be great, is that we can lookup users by their addresses. And now you find yourself having to deal with these additional addresses columns all over the place, and here starts your ball of mud.

I think you see my point. The problem is not a question of money, it is very much a problem of understanding the underlying structure of a project.

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

#57

Post by robmccoll »

The main thing that resonated with me is keep your software simple. Don't try to be cute or clever. Don't whip out your favorite OO design pattern when a simple function will do. Don't try to optimize the function you spend 1% of your time in. Follow Unix design principles. Simple is easy to maintain, easy to debug, easy to learn, easy to understand. Impress your peers by writing good code that works well rather than code that only you understand (and even then you will have to relearn when you come back to it in six months).

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

#58

Post by dba7dba »

robmccoll wrote: post #57

The main thing that resonated with me is keep your software simple. Don't try to be cute or clever. Don't whip out your favorite OO design pattern when a simple function will do. Don't try to optimize the function you spend 1% of your time in. Follow Unix design principles. Simple is easy to maintain, easy to debug, easy to learn, easy to understand. Impress your peers by writing good code that works well rather than…

If I may dare to add:

... writing good code (that others, including yourself 1 year from now, can maintain easily) that works well ...

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

#59

Post by sethammons »

wvenable wrote: post #53
Kenji wrote: 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've only recently started working for larger more corporate-type firms and it's absolutely amazing how much they pay for giant ball of mud software. Astronomical amounts and then on top of that there are maintenance fees, support fees, upgrade fees. It's absolutely amazing and frightening the money being spent. So I think the problem isn't money; the real problem is there just isn't enough software! We have a softwa…

if you don't mind sharing, what industry/niche?

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

#60

Post by landongn »

ams6110 wrote: post #41

The Big Ball of Mud is not unique to software. Ever been in a building that's had a lot of renovations and additions? There are weird half-flights of stairs here and there, convoluted paths from one side to the other, different styles of fixtures, etc. Eventually they get to the point where it's easier and cheaper to just build a new building somewhere else, or tear the old one down and start from scratch. Just like…

Absolutely true. Shantytowns are a common parallel to big balls of mud, and I think that would hold true for anything that gets constructed.
Post reply on HN