5 ms·
I believe the relative ease — not to mention the lack of tangible cost — of software updates has created a cultural laziness within the software engineering
by rkagerer 8y ago
I believe the relative ease — not to mention the lack of
tangible cost — of software updates has created a cultural
laziness within the software engineering community.
-- This --^
As someone who carefully crafts their code to strive for perfection, seeing sloppy work out there in the wild drives me nuts. I know folks here will deride me for being "inefficient", but in the long term I still maintain from my experience it's less efficient to push out buggy software and try to fix it retrospectively.
- rubicon33 8y agoIf only managers and CEOs saw it the same way.
- winrid 8y agoAt my current company all leadership is in agreement that it is more expensive to deal with bugs in production.
- Frost1x 8y agoBut CD...agile... It really depends on the scenario. If you can bill those fixes to the client or if you have to eat the cost to make the fixes. Most modern development processes seem to push this model simply because they can essentially pass the costs to the client and charge other or future clients for the improvements.
- winrid 8y agoWe charge upfront for someone to use the product and negotiate any feature requests.
- WalterBright 8y agoYou'll see it in any piece of software written by any developer who is self-managed. The notion that software quality would greatly improve without managers is a myth.
- andbberger 8y ago[citation needed] idk man, my code is pretty damn clean
- alacombe 8y agoCode cleanliness has no correlation with lack of bugs. Also, 1) your sample size is pretty small, and 2) what looks clean to you might very well be despicable to someone else.
- blunte 8y agoAnd more importantly in this case, the appearance of your code is relatively meaningless compared to you failing to consider all cases of inputs. Honestly, the appearance of code is irrelevant. The goal is to absolutely accurately meet the requirements - the true, actual requirements. It may not be within scope to know all the information you need to know to cover all the cases, and that's certainly a problem. But the cleanliness of your code, assuming it functions correctly, is unimportant to the operation. (It certainly will be a maintenance cost, though.)
- onemoresoop 8y agoThe actual argument is that code cleanliness improves readability which in turn makes finding bugs easier and also eases the conceptualizing of what the code does. I'd say it's first line of defense against bugs.. tests could miss bugs too but that doesn't mean we shouldn't test thoroughly
- andbberger 8y agoI guess that was a poorly chosen word on my part then. How about 'elegant'.
- ncmncm 8y ago"Elegant" does't mean "right" either. But with elegant code it is often easier to tell if it's not right, and also how to get it right if it's not. Often that requires making it less elegant, because the real world rarely poses elegant problems. You want to ensure that as much as possible of the necessary inelegance is at the top level, with everything below clean.
- alacombe 8y agoOne the other side, unless you are an artist and not dependant on your software actually being used, you have to get product out at some point. It's easy to demonize CEO and managers. We, as devs, will always find an excuse as to why the software is not ready and QA will always find new things to test to justify not putting the software out.
- Frost1x 8y agoIt depends on the real world effects of pushing software out. If the side effects are minor and its perfectionism, then sure, push it out ugly. If it's a safety control mechanism for a car or airplane, then perfectionism needs to be applauded over faster time-to-market. If it's another chat application and changes can be easily rolled back, then push it out warts and all.
- Gibbon1 8y agoI think that 'can safely ship' is primary feature of any software project. What the means in practice is it puts pressure on new features and 'refactoring'
- airbreather 8y agoIf you have fully defined what your software will do up front, then you are finished when have made it do what you said it would. Safety critical software is usually designed, built and tested to the V-model. When done properly every piece of logic/code can be traced back to a requirement through all steps and phases of development and testing. There is no "move fast and break things" in the safety instrumented field, the engineering hours per byte/instruction delivered would absolutely flabbergast most software devs, by many orders of magnitude.
- rdiddly 8y agoThe most efficient way to do it is to do it once.
- atoav 8y agoWhich leads to the heart of the discourse: programming is many things at once. Programming a single purpose library or module who has to do one thing and this one thing as good as possible demands efficient and sustainable solutions. Theoretically if you get that kind of code just right, you don’t have to touch it again for a long time. On the other hand you have code where the codes environment is so volatile or ephemeral, that developing the appropriate code isn’t possible, because you are aiming at a moving target. This often demands faster solutions, shims, code that was never really meant to be maintained etc. Sadly many companies have a culture where these shims become like glorified tradition and a few years down the line you have a pile of shims that nobdy sane is willing to touch. However there are situations where fast solutions make sense, e.g. because it is a one time thing or it doesn’t really matter that much etc.
- baddox 8y agoThat is definitely not true for all tasks, and especially not all software engineering tasks.
- blunte 8y agoIndeed, but the prereq is that you know the need absolutely and correctly initially. And you usually don't.
- adreamingsoul 8y agoRecently, I had someone join my team who was instantly popular and everyone enjoyed this person's personality. I trusted this person more then I should have and during a period when I was unable to give enough attention to their code reviews, they introduced several critical bugs and defects into the production environment. I never figured out if it was ignorance or laziness. But, either way I learned a valuable lesson. It was also a reminder to me that not everyone has the same level of ownership or commitment that I would expect.
- crescentfresh 8y ago> not everyone has the same level of ownership or commitment that I would expect This is a good way of putting it. A dev might be junior and won't have the knowledge or skill to build stuff with minimal defects, but they can still have the sense of ownership and commitment to a quality product that a senior/trusted dev on the team has.
- underwater 8y agoIf the only gatekeeper against shipping bugs is a senior engineer catching bugs in review, then that's possibly a sign that your processes need improvement, rather than the people.
- tremon 8y agoNot rather; in addition to would be more appropriate.
- quickthrower2 8y agoThey are new to the team and are not getting sufficient code reviews. I wouldn’t put the blame on them. There is a lot of gotchas in an unfamiliar codebase. Although they probably should have known this and insisted on a full review if they are at senior level.
- megaremote 8y agoMaybe, but code reviews don't catch everything. They never can. Relying on them can also be a mistake.
- amelius 8y ago> As someone who carefully crafts their code to strive for perfection, seeing sloppy work out there in the wild drives me nuts. Do you use formal methods to prove the correctness of your code? Because that is what Boeing engineers do (I hope).
- deleted 8y ago[deleted]
- philjohn 8y agoYou would indeed hope. But then again, look at the Toyota ECU issues ... and the subsequent code review as part of the court case ...
- Raidion 8y agoIt's not the logic that's the problem as much as the fact that the systems are meant to work with clean data, and the fact that data could not just be missing, but straight up incorrect was never considered as a valid possibility. This was made worse by the fact that the poorly formulated "solution" was barely communicated to the pilots. I saw somewhere that the plane could be unrecoverable in 40 seconds. You need to have bigger safety margins than that.
- ncmncm 8y ago40 seconds is an eternity to a pilot taking off or landing. Even Air France, taken down by a plugged pitot tube from cruise altitude, was doomed after only two minutes. Airbus has a lot to answer for on that one: averaging inputs from the pilot's and copilot's game controllers? Game controllers? Turning off the stall warning in deep stall, so that starting to recover sounds it again? Failing to teach pilots what stalls are, what they feel like, and how to prevent and recover from them? There is more than enough blame to go around for that one. The Boeing software, like the Airbus's, apparently performed as specified, so there was no problem with execution of the spec. The problem was that it was a bad spec, in too many ways to count.
- philipov 8y ago"Beware of bugs in the above code; I have only proved it correct, not tried it." - Donald Knuth
- baddox 8y agoIt definitely depends what you're doing. Designing aircraft control systems? Yep, probably strive for perfection. Building a social network site, or a photo-sharing site, or an online forum? You're probably okay sacrificing some level of reliability for iteration speed.
- Retric 8y agoIt’s less about the domain than the impact of the code. Bad code can kill your company or go unnoticed, depending on where it is and what it’s doing.
- baddox 8y agoOf course, but the solution for the vast majority of companies and projects isn't "never release code that isn't perfect."
- Gibbon1 8y agoI wrote a buggy POS test program that had race conditions because I didn't really understand what I was doing. And sometimes it would assign two units the same serial number. It would check once the test was done and just fail one of the two if that happened. And the tech would just rerun the test on that unit. In the big scheme of things no one cared.
- anbop 8y agoWell, great code is inefficient if the impact of bad code is minimal. If you are shipping an animated emoji you should be sloppier with your code than if you are building flight control software. Overengineering software is like over-specing building materials by 10x and spending way more money on a building than it needs.
- Raidion 8y agoI agree, but practically a lot of bad software practices happen when middle management don't fully communicate the tradeoffs that are made when designing and building software. I find it hard to believe that this was a problem that no one really saw coming, but just didn't get flagged at a level that was needed to investigate it.
- tremon 8y agoAnd in that same line of argument, great code is inefficient if the bad code can always be fixed post-release. Never mind the consequences of the first release, if we sell enough of it we might be bothered to pick up our slack 2 years from now.
- blunte 8y agoI think you vastly underestimate the scale of an aircraft in whole. Your code is one thing, but the many systems it interacts with, the systems they interact with, and the possible outcomes, is almost unfathomable to a human. And even in simple cases where the number of possible situations is calculable, you probably haven't covered all possibilities.
- mathgenius 8y agoThis was not buggy software. This was a bad specification. The software did what it was supposed to do.
- ncmncm 8y agoAnyway, specified to do.