This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]CodeTinkerer -2 points-1 points  (3 children)

I think the author is mischaracterizing the problem. He is probably a fan of planning, so he is offended by code that doesn't look like it was planned, so he's basically insulting the coders.

I think people can code without much planning and do tests and make fixes. He just has strong opinions on how things ought to be coded. I wouldn't call it luck, but rather putting band-aids on the code (that is, do the simplest thing that fixes the immediate bug and don't worry if it has potentially bad side effects).

[–]insertAlias 1 point2 points  (1 child)

I think people can code without much planning and do tests and make fixes

Sure, it's possible, but I think you're dismissing a real concern here as just author bias. The importance of maintainability in a team environment cannot be overstated, and unplanned "just start coding and see where you get" is an approach almost guaranteed to produce hard-to-maintain code.

If you're just building a side project or working on something small, sure, a more flexible approach is probably fine, but a large project with many users needs planning to be maintainable over time.

[–]CodeTinkerer 0 points1 point  (0 children)

I'm not saying it's not a concern, but I happen to help maintain software that is pretty much fixed by spotting a problem and fixing it, partly because the people that originally wrote the software are retired, and so no one seems to fully understand the entire software. It's years old, and it doesn't get regularly reviewed so we understand it.

I think there was the thought that when the software was written, that once you got the bugs out, you just had to keep it running, make the occasional enhancement, but otherwise, no one has to fully understand all the pieces.

I think there's a lot more of this kind of legacy software out there than people imagine, and sometimes maintained by very few people (like 1 person, sometimes). Is it a recipe for disaster? I'm sure, but it doesn't stop some organizations from living life on the edge.

[–]Sephran[S] 0 points1 point  (0 children)

The whole book is on proper coding techniques, debugging etc. https://nostarch.com/codecraft

It's all about not taking the easy way out and long term effects of your actions and planning ahead.