3 ms·
I was actually thought how to build quality software (which is not limited to "having no bugs") in college, but I do not have the time or resources to apply thi
by slily 3y ago
I was actually thought how to build quality software (which is not limited to "having no bugs") in college, but I do not have the time or resources to apply this knowledge consistently in a corporate setting because of the pressure to deliver.
- groestl 3y agoBecause frankly, too much quality is not necessary, in many many cases. To know when you should or should not emphasize quality over quantity and speed, to meet a certain financial objective, is actually harder than writing quality software in the first place, I think.
- slily 3y agoI agree in principle, but in my experience quality is not nearly prioritized highly enough. There is not enough understanding of quality attributes beyond the most visible ones like compute performance and stability (i.e. lack of bugs). And even for those I work on projects where people complain about lack of proper test coverage constantly, but it is impossible to dedicate time to improve that.
- groestl 3y ago> in my experience quality is not nearly prioritized highly enough I agree with you on that one. IMHO it's because of that difficulty to know when to optimize for quality, but also because of sheer incompetence.
- Xeamek 3y agoI'm pretty sure even those basic two, of performance and stability are extreemely undervalued, when you objectively look at how fast modern hardware is and yet how easy it is to find slowness simply in using devices in a day to day environments
- Xeamek 3y agoThis is false. Its just that the costs of low quality code are much less obvious and harder to measure then the dev time. But the ammount of bad code just piles on itself over and over and over and we end up in a world where hardwares becomes incrementally faster while software becomes slower and slower, and more bugier. I mean, in the strict sense of the world an individual company will not pay those costs, but on a societal scale, how much time (and thus money) is wasted daily by all the people who are waiting 30secconds for windows explorer to load? If your app have millions of users, literally every additional second your app wastes multiplies to tangential numbers. It's akin to pollution, really: Individual company making 'dirty' things won't see the consequences. But scale this mindset out and suddenly we wake up in a world when trillions of dollars are spend to counteract those effects.
- groestl 3y ago> This is false. I wonder where you get the confidence to make such a strong statement, which is clearly not warranted. I want to challenge you to broaden your view a bit: Not a lot of software is like Windows explorer. Not a lot of software is performance critical. A lot of software can do with bugs, with many many bugs, to be honest. A lot of code is run fewer than 100 times, before it's retired. Also, not a lot of software written has many users. Or enough users to support maintaining it. "Pollution" often affects just the author of the software themself. Software is just a means to an end, and the end decides, how much effort was warranted in the first place.
- Xeamek 3y ago>Not a lot of software is performance critical. Not being performance critical doesn't mean it is justified to diss-respect users by wasting their time. >A lot of code is run fewer than 100 times, before it's retired. Also, not a lot of software written has many users. Obviously we aren't talking about some simple automation scripts here. >"Pollution" often affects just the author of the software themself. You are misunderstanding the pollution analogy. I'm not talking about polluting the codebase with code smell. I am talking about costs of low quality being non obvious and only revealing themselves at global scale
- teknopaul 3y agoMe too, Manchester uni was good. I have written non-trivial systems deployed in 20 different sites that have never had a bug ever. My best are usually second systems, focus on simplicity, standardisation and resist scope creep. 100% coverage with unit tests. 100% coverage with integration tests. I've written a many things with zero bugs after delivery. (and other that were never ending quality nightmares) If I am under pressure to deliver I get strict with TDD, since no time for bug fixing.