141–150 of 601 posts
I’d like to hear people describe why the code they’ve seen is bad.
Earlier quoted context omitted.
> They go down often Isn’t that one of the two main features of the product?
"to go down" means "to be in a non-functional state" as in "Facebook went down". Compare to "to go up" like "servers are up" i.e. servers are functioning.
Earlier quoted context omitted.
> an elevator is a precisely defined problem Ha! As a mechanical engineer, no, nothing in reality is ever precisely defined. Consider that every single part in the elevator has a tolerance: none of the parts are exactly the same in every elevator. Did you account for thermal expansion? What about wear? Fatigue? > Software is never like that — it’s dynamic and constantly changing throughout the life cycle of the softw…
> with software, it almost never works perfectly no matter how much time passes. There is a person inside me -- whenever this is said -- that wants to shout "No! You can prove correctness of your program!". But this complicates the issue even more, since afaik no elevator's correctness is proven but it just works. Mechanical stuff somehow just magically work without proof whereas it's still debatable if proven softwa…
It might seem like magic, but, of course, there is actually a science to it. Depending on the situation, a part can work if a certain length is 10.000 or if it's 10.001. In software, that is never the case: a value that should be 10 but is actualy 10.001 can stop everything. In engineering, there is a limited amount of leeway at every step of the process, and everything is slightly overengineered by some factor of safety to ensure that this is the case. For example, if an elevator cable is rated to hold 10,000lbs, the elevator will be sold as having a maximum capacity of 8,000lbs. In correct usage, (weight less than 8,000lbs), there is a sufficient factor of safety on the cable so that it won't break even if the cable is cracked, worn, etc.
Lots of microservices, before it was cool, that was fine. Shitty code everywhere, commented code, dead code, 5 blank lines here and there. Many lines over 100 chars, lots pushing 150 or 200+. Didn't understand how to use argparse or logging but tried. Crazy mixed-case WTFExtremelyLongSillyNamesEverwhereSendThis at the command-line interface, instead of verbs like send.
Had a custom ORM that didn't want to look like one and took 5 times the code to do similar things. Little handling of exceptions, things like wrong permissions or IO like tar file creation might cause a 6 hour job to crash.
Daemons couldn't be shutdown gracefully, had to tail their logs until they paused for a moment, cross fingers, and kill process, often kill -9. Old daemontools made it more difficult. Bad timing could mean you are in for 3 to 6 hours of manual job cleanup work. Would happen a few times a week anyway, cutting into dev time. Still you could count on it to work about 90% of the time.
Token test suite and docs. Embarrassing web interface that would look amateurish in the 90's. Original developer made us do a standup everyday at 10:30am just when getting into the zone. They felt worthless for a while, and then it dawned on me why, we were all working on different projects.
The punchline: spent three months of 60 hour weeks taking out the trash, writing tests, paying down debt. Spent the next month or two with another dev designing/writing a vastly improved V2 with graceful shutdown, Django-style ORM, and quality as headline features.
A few weeks before we're about to knock it out of the park and deliver, the old author of V1 comes back in a panic, says we need to finish at end of month as a huge project is finishing. Doesn't seem to make sense, big changes at end are a bad idea. Takes over control of project, designs/implements V1.1, pushing aside our improvements and whips it up in a few weeks while I sit there with nothing to do. 6 months work of 60 hour weeks flushed down toilet.
After picking jaw off floor and offering a few choice words I left the job by mutual agreement a few weeks later and didn't look back. Good times.
Here's a metaquestion: Is it possible for any codebase to NOT eventually (given enough time) become a crufty pile of garbage? I suspect (but have no real evidence... yet) that SOME of this spaghetti garbage is due to the traits of procedural, OOP, mutable languages. But this would then imply that things like functional-language codebases have much longer lifespans... and I don't have evidence for that... but I'm hopi…
Also the quality of the test suite makes a huge difference in combination with the willingness of developers to refactor. No testsuite automatically means no refactoring. With a testsuite the question remains whether the organization penalizes or encourages larger code changes (sometimes with old code bases managers demand pinhole-surgery only).
And then there is this funny thing that perfectly acceptable code bases age without a change to their code. Idiomatic C++ code from the 90ies is from our perspective not clean, even if the person who wrote it was a dedicated and smart programmer following the best practices that they could get a hold on.
With functional code bases you might see similar patterns. A Haskell person of today may look at an older common lisp code base with similar reservations as a java programmer to the visual basic 3 app.
I just sat down and wondered how a tech stack potentially used by a startup could age. In the future i think we will see much more dependency problems. When you get to maintain a Django/nodejs/ruby on rails application, you always take pypi/rubygems servers for granted (or your local mirror on artifactory). Think about the time in 40 years when the dependencies are not available. Or the small languages we sometimes see and still are able to find tutorials for, how will it feel to take over a Lua codebase in 40 years? I hope that enough docs stick around, but already when I browse the web on Smalltalk stuff most links are broken because actually information can disappear from the web.
Or database technology. How will that NoSQL db appear to a maintainer in 30 years?
So while today we are unhappily having to maintain software that was written without version control, it may be that future generations will have it even worse because they dont even have a monolithic code base in front of them but something with dependnecies they cannot install anew anymore.
Any large company. I’m being serious. As a development coach I see a lot of code and I must say the DEFAULT is “how does any of this even work?”
I've been working on fixing some old C++ code at my company so that it compiles with the most recent version of the compiler. To my surprise, the errors that the new compiler gives me are very reasonable. But I always ask myself, "how on earth did this ever compile in the first place?" The crazy part is going into the commit logs and seeing that a lot of the people who wrote this have been very successful. They've be…
We've got another codebase of similar vintage that is preventing us from deploying spectre patches...
Here's a metaquestion: Is it possible for any codebase to NOT eventually (given enough time) become a crufty pile of garbage? I suspect (but have no real evidence... yet) that SOME of this spaghetti garbage is due to the traits of procedural, OOP, mutable languages. But this would then imply that things like functional-language codebases have much longer lifespans... and I don't have evidence for that... but I'm hopi…
It's comfortable to blame the tools but in my experience it's a people problem, not a tool problem. I've looked back on my own code from years ago and wondered what I was thinking! I'm currently rewriting one of my own projects because it was done in a hurry with the requirements half-specified and my heart was not in it.
But I've seen things from other people, insane twists of logic that can hardly be imagined.
One of the projects I don't work on originates from the 80's. There is tons of actual code from the 80's in this product. It has a Windows GUI. It has a web interface. It started out on Unix at some point but now runs on Windows. It's written in a language that doesn't exist anymore. It costs millions of dollars. OOP vs. Functional is not really the question.
Years ago as an intern at Microsoft, I had code go into the Excel, PowerPoint, Word, Outlook, and shared Office code. Excel is an incomprehensible maze of #defines and macros, PowerPoint is a Golden Temple of overly-object-oriented insanity, and Word is just so old and brittle you'd expect it to turn to dust by committing. There are "don't touch this!"-like messages left near the main loop _since roughly 1990_. I had…
Years ago as an intern at Microsoft, I had code go into the Excel, PowerPoint, Word, Outlook, and shared Office code. Excel is an incomprehensible maze of #defines and macros, PowerPoint is a Golden Temple of overly-object-oriented insanity, and Word is just so old and brittle you'd expect it to turn to dust by committing. There are "don't touch this!"-like messages left near the main loop _since roughly 1990_. I had…
"Don't touch this" around the main loop can mean being able to make promises about responsiveness, reliability, etc. Frequently there are critical code sections where it is much easier to tell people "don't touch it" rather than training people how to work on it safely.