Title could have been less clickbaity
Software development is a loser’s game
81–90 of 159 posts
Re: Software development is a loser’s game
#82> If we invert software development, the goal isn’t then to write code that works, it’s spending time on avoiding writing poor quality code and bugs. This line is packaged to sound really insightful, but is it? The goal of software development is to create software in support of some greater mission. That mission might be to make someone's life easier, to make money, to advance human knowledge, or many other things.…
> The goal of software development is to create software in support of some greater mission If that's the goal - the only goal - then all code is equal, and it doesn't matter how it's written. So... go crazy? Use global variables and goto statements? Hardcode path names and don't bother with build scripts? Writing software that works is challenging, but writing software that can be safely modified is even more so.
Right, but in most cases, supporting a greater mission is a marathon, not a sprint, so bad code in an early version is very painful later, and detracts from the long term mission.
You gotta think long term (usually)
Re: Software development is a loser’s game
#83An ask of anyone reading this article: Please don’t let yourself become a smug or cynical programmer. Too many programmers read articles like this and assume that they are the 20% of good programmers while everyone who disagrees with them is the 80% of amateur developers: > I have worked in software development for 20 years, worked on many projects with many software developers. I estimate 80 percent of software deve…
I see this as a false dichotomy - the real most correct way is less expensive, it's just that quite often people who think they're aiming at perfection are instead actually experimenting with different approaches at random with no clear benefit.
You don't need to cut corners to achieve cost effectiveness and tech debt is just that - debt, which always has to be paid eventually - either through expensive bugfixing, a rewrite or bad user experience.
The project's I've been in that went over budget usually had one or more of the following:
-Too large of a scope vs budget.
-Bad or no architecture whatsoever.
-Increasing personnel instead of reducing scope.
On the other hand projects with an architecture, a set of clear conventions and flexible scope fared much better.
Re: Software development is a loser’s game
#84If you’re tired of software dev try http://programming-motherfucker.com/ instead.
Re: Software development is a loser’s game
#85>80 percent of software developers are amateurs and 20 percent professionals. Why do I say this? >Amateur software developers dislike - Standards - Unit testing - Design patterns/SOLID principles - Learning and setting DevOps and ALM (They like using it) - Fixing the build - Code reviews - Code Analysis/Solution checking What a troll statement, no way do 80% of software developers dislike those things.. maybe.. 20%?
I've had the misfortune of working at a few places were many/most of these things were pretty universally frowned upon.
> - Standards
Resistance to using formatters and linters because they prevent you from merging code more quickly; "it's annoying". Two of the two-dozen devs on the product decide that they want to use NetBeans instead of Eclipse even though the formatter is built for the the latter and everybody else uses it so they can't format their code properly.
> - Unit testing
I recently went four years without writing a single unit test professionally. When I _did_ write unit tests I worked on one team where the only important metric was coverage percentage, not corner/edge cases or intentionally trying to break the software. People would write tests for auto-generated getters and setters in C#. That's right - they would _test the compiler_ just to satisfy a business metric.
> - Design patterns/SOLID principles
My tech lead at a previous job refactored a pretty substantial service I wrote with no team input to remove any semblance of organization or convention. The repositories, factories, and facades I built got merged into a giant single "helper" object just to follow some weird anti-pattern that they'd established. It wasn't testable, there was no separation of concerns, and it ended up being nigh-unreadable.
> - Learning and setting DevOps and ALM (They like using it)
> - Fixing the build
I've been the "CI guy" at almost every software job I've had because some people are afraid of the command line and lack an understanding of the build tooling outside of the three SCM operations they know through Tortoise and the play button in their IDE.
I could go on but you get my point. Software development is a vast industry and there are some pretty dark corners. For every high-performing team that has tech-savvy devs there are body shops full of people that are trained by rote to "build software". It's not pretty.
Re: Software development is a loser’s game
#86To be fair, a lot of traditional science and engineering follows the same pattern. I'm a SW dev embedded in an R&D engineering organization and the main difference is that SW development has faster cycles and less established practices but if you scale up SW dev timelines to match ME and EE cycles it's not that different.
Preventing bugs is something especially our materials and system interaction engineers are very aware of. You don't want a consumer product to fail in the field and cause damage or harm so that's goal #1.
Re: Software development is a loser’s game
#87Because long-term maintenance isn't the concern. Most devs switch jobs in 2-5 years (or at least that's the common advice given). So the incentive is to play musical chairs, and hope that you've moved on by the time the music stops. Software has also been such a new field that it was the startup that moved fast and broke things that got the prize rather than the slow but stable company. I think this is changing (lowe…
I think the heart of this isn't devs changing jobs. It's execs. I know plenty of devs who will be "irrational" about quality in that they build for sustainabilty and longevity far beyond their personal economic incentives. But when those same devs go up the chain to improve practices or clean up tech debt, they rarely end up happy. I think that's because executive turnover is also fast and the rewards for underinvest…
I've rarely seen progress get made when it's framed as "I want to clean up tech debt." To execs it seems like moving deckchairs rather than moving the number (which to be fair, it sometimes is).
"In order to release feature x which customer y cares about, we need to clear up tech debt / refactor z" is a much better way of getting execs on board.
Re: Software development is a loser’s game
#88> If we invert software development, the goal isn’t then to write code that works, it’s spending time on avoiding writing poor quality code and bugs. This line is packaged to sound really insightful, but is it? The goal of software development is to create software in support of some greater mission. That mission might be to make someone's life easier, to make money, to advance human knowledge, or many other things.…
> The goal of software development is to create software in support of some greater mission If that's the goal - the only goal - then all code is equal, and it doesn't matter how it's written. So... go crazy? Use global variables and goto statements? Hardcode path names and don't bother with build scripts? Writing software that works is challenging, but writing software that can be safely modified is even more so.
I mean, if the only requirement is "have software that works", yea, go nuts. Look at a ton of tech demos, working is the goa the goal, the code sucks, it's fine, it's gonna be rewritten anyway.
Practically the requirements are "have software that works, and will be sustainably developed and improved for 5 years". Making the trade offs in terms of "perfect code" to "good enough code" is what makes a software developer (in most settings) go from "good" to "great". Good software engineers can see all the edge cases and future paths. Great software engineers can prioritize those against business goals.
Just like "global variables and goto statements" is bad, so is "perfect, provably correct, and overtested" code in the vast majority of business settings.
Re: Software development is a loser’s game
#89more previous discussion from a few days ago: https://news.ycombinator.com/item?id=26630731
Re: Software development is a loser’s game
#90> Unit testing In the game development, videogames are primarily tested by humans. Games are highly interactive pieces of software often running on a variety of hardware with complex agent-based simulations. Are all game developers "amateurs"? I don't think so.
Yeah, I couldn’t find the dev ops folder or the unit test folder in the Linux kernel sources either.
Any idea on how they get the kernel to scale without kubernetes?