4 ms·

After almost 10 years working in corporations and in the government, I can't help but think that Dijkstra's call for quality rings truer than ever. It's appalin

by lp4vn 3y ago

After almost 10 years working in corporations and in the government, I can't help but think that Dijkstra's call for quality rings truer than ever. It's appaling the amount of projects that get killed not only because they were poorly executed but also because they were completely useless in the first place. In this day and age we live in a kind of stupor that we have to keep the wheel of economy spinning no matter what and that as long as someone is paying we have to keep sh*tting lines of code for perpetually late projects. It's like we're inefficient on purpose. Look at the shitshow that the SCRUM method is for instance. We are purposefully distancing software development from any kind of rigorous method, it's a real tragedy.

shiandow 3y ago
No amount of mathematics is going to prevent you from making something nobody needs. It will work beautifully though.
- usgroup 3y ago
  Ah good, because the sort of rubbish I suspect OP is referring to also usually contains "no amount" of mathematics too :)
  - shiandow 3y ago
    As a mathematician I'd point out that 'None' is also an amount ;-)
    - usgroup 3y ago
      Pedantry on my part, but would you say that a non-existent unicorn weigh some amount "None"? That'd be strange to me, and "no amount" would describe such a situation.
      - shiandow 3y ago
        That hypothetical has very little to do with the situation at hand. Badd software clearly exists and it is possible to talk about how much mathematics went in it. If no mathematics went in that's still an inidication of 'how much' and therefore is an amount.
        usgroup 3y ago
        "A non-existent amount of mathematics" -- which the joke could have been interpreted as implying -- is not zero mathematics: that would be an existent amount. Another place these semantics arise is in talk about probability and possibility, wherein the possible can have zero probability (e.g. any specific value in a continuous probability distribution), but the impossible cannot have a zero probability because by definition it is outside the set of "possible events" (measure theoretically). Both make little intuitive sense.
elric 3y ago
Scrum is not an acronym, there's no need to write it in all caps. Scrum is not intended to remove rigour from development. It acknowledges that people (the client) have no clue what they want (they're no Mozart), and that it's up to the development mean to help them figure it out. Ideally converging on something that the client wants, and works well. Sure, plenty of projects fail for a variety of reasons. And sure, scrum (or agile in general) isn't perfect. But it's the best tool in our toolbox at the moment. You, and all those other folks who like to tilt at the scrum windmill, are more than welcome to propose something that works as well as (or better than) scrum without the downsides. But so far, it's been crickets. IMO there are three big issues: clients don't understand software development, and management doesn't understand software development, and software developers neither understand clients nor management.
- lp4vn 3y ago
  If you think that it's the role of a developer to figure out what a client wants, then well... We have completely divergent views of how the the process should be. A software developer should develop for a specification, he or she should not be there to entertain clients in a game of creating a product. It's not that scrum is not perfect, scrum is an absolute garbage that unfortunately today fits very well with the micromanaging hunger of managers, no method is better than scrum.
  - Jtsummers 3y ago
    > A software developer should develop for a specification, he or she should not be there to entertain clients in a game of creating a product. That's a sad view. Reminds me of a couple past managers I've had who thought that software developers were assembly line workers. US culture note: The cultural expectation for assembly line workers here is that they "shut up and color", it's the job of the managers and engineers to do the thinking. That is, even if an assembly line worker can see that something is wrong, it's not their job to point it out or fix it. They are disempowered in this culture. What's sad about your view is you similarly want to disempower developers. You don't want them to have input into what they're making, you just want them to shut up and code. According to you the specification is, what, always given to the developers without their input? So if the specification is non-viable they should just accept it and sit in their corners making nonsense?
usgroup 3y ago
This rings true in my experience too. It isn't even artisanal code lacking an end user, its garbage code that barely works which no-one wants. Luckily I've spent most of my time in the start-up space where things working is a more existential concern, and the sort of thing mentioned above is less of a problem.

by lp4vn 3y ago

shiandow 3y ago

No amount of mathematics is going to prevent you from making something nobody needs. It will work beautifully though.

usgroup 3y ago
Ah good, because the sort of rubbish I suspect OP is referring to also usually contains "no amount" of mathematics too :)
- shiandow 3y ago
  As a mathematician I'd point out that 'None' is also an amount ;-)
  - usgroup 3y ago
    Pedantry on my part, but would you say that a non-existent unicorn weigh some amount "None"? That'd be strange to me, and "no amount" would describe such a situation.
    - shiandow 3y ago
      That hypothetical has very little to do with the situation at hand. Badd software clearly exists and it is possible to talk about how much mathematics went in it. If no mathematics went in that's still an inidication of 'how much' and therefore is an amount.
      - usgroup 3y ago
        "A non-existent amount of mathematics" -- which the joke could have been interpreted as implying -- is not zero mathematics: that would be an existent amount. Another place these semantics arise is in talk about probability and possibility, wherein the possible can have zero probability (e.g. any specific value in a continuous probability distribution), but the impossible cannot have a zero probability because by definition it is outside the set of "possible events" (measure theoretically). Both make little intuitive sense.

elric 3y ago

Scrum is not an acronym, there's no need to write it in all caps. Scrum is not intended to remove rigour from development. It acknowledges that people (the client) have no clue what they want (they're no Mozart), and that it's up to the development mean to help them figure it out. Ideally converging on something that the client wants, and works well. Sure, plenty of projects fail for a variety of reasons. And sure, scrum (or agile in general) isn't perfect. But it's the best tool in our toolbox at the moment. You, and all those other folks who like to tilt at the scrum windmill, are more than welcome to propose something that works as well as (or better than) scrum without the downsides. But so far, it's been crickets. IMO there are three big issues: clients don't understand software development, and management doesn't understand software development, and software developers neither understand clients nor management.

lp4vn 3y ago
If you think that it's the role of a developer to figure out what a client wants, then well... We have completely divergent views of how the the process should be. A software developer should develop for a specification, he or she should not be there to entertain clients in a game of creating a product. It's not that scrum is not perfect, scrum is an absolute garbage that unfortunately today fits very well with the micromanaging hunger of managers, no method is better than scrum.
- Jtsummers 3y ago
  > A software developer should develop for a specification, he or she should not be there to entertain clients in a game of creating a product. That's a sad view. Reminds me of a couple past managers I've had who thought that software developers were assembly line workers. US culture note: The cultural expectation for assembly line workers here is that they "shut up and color", it's the job of the managers and engineers to do the thinking. That is, even if an assembly line worker can see that something is wrong, it's not their job to point it out or fix it. They are disempowered in this culture. What's sad about your view is you similarly want to disempower developers. You don't want them to have input into what they're making, you just want them to shut up and code. According to you the specification is, what, always given to the developers without their input? So if the specification is non-viable they should just accept it and sit in their corners making nonsense?

usgroup 3y ago

This rings true in my experience too. It isn't even artisanal code lacking an end user, its garbage code that barely works which no-one wants. Luckily I've spent most of my time in the start-up space where things working is a more existential concern, and the sort of thing mentioned above is less of a problem.