101–110 of 122 posts
Earlier quoted context omitted.
"We get the software we deserve." Painfully true. There are techniques for writing better software. They work. They take longer and cost more. They are not widely used outside aerospace.
Also in medical devices. IIRC FDA has standards for software writing/testing/certification.
Unless you’ve written a buggy program, you don’t realize that you’re addressing our intellect. This is why I think that every engineer on the planet looks at a bug report and feels a twinge of pain as they read whatever detail that was left to serve as a figurative shame sticker on the report card of their creation. It really sucks when you’re just flat out wrong. Being wrong — rather, being incorrect — is an extreme…
Bugs in a tracker don't hurt, bugs not in a tracker hurt.
There's really one issue here. Budget. You want two pairs of eyeballs on everything as you write it? Okay. Pay two guys. You want complete test coverage? Okay. Can take as long as writing the code itself. Maybe more. You want full documentation? Okay. Guy can't spend as much time on coding. You want new APIs to be included? Okay. Guy's got to read docs and try samples. Less time. What I've seen is you always end up w…
Earlier quoted context omitted.
> The moon landing really was nothing compared to this. I used to believe that, but I have slowly moved to the other side. Things are complicated. There is no doubt about that. But, landing on the moon was a fight against nature (gravity, air, distance, etc). Current programming is a fight against stuff someone else dreamed up and no one ever fixed, because "LOL, that's old school" or "You're just doin' it wrong". Mo…
Except it's an applies-to-oranges comparison to start with. The mathematics of space-travel is very simple - it's just calculus. You need to be accurate, but it's easy to quantify and well controlled. Which is why you can go to the moon with a decent graphics calculator, but you definitely can't have a self-driving car with much less then a modern supercomputer.
We're not talking about calculating our way to the moon. We're talking about going to the moon.
The space program had much more than a graphing calculator. They had buildings full of people, systems, and realtime communication with the craft.
Earlier quoted context omitted.
I've only recently started working for larger more corporate-type firms and it's absolutely amazing how much they pay for giant ball of mud software. Astronomical amounts and then on top of that there are maintenance fees, support fees, upgrade fees. It's absolutely amazing and frightening the money being spent. So I think the problem isn't money; the real problem is there just isn't enough software! We have a softwa…
if you don't mind sharing, what industry/niche?
There's really one issue here. Budget. You want two pairs of eyeballs on everything as you write it? Okay. Pay two guys. You want complete test coverage? Okay. Can take as long as writing the code itself. Maybe more. You want full documentation? Okay. Guy can't spend as much time on coding. You want new APIs to be included? Okay. Guy's got to read docs and try samples. Less time. What I've seen is you always end up w…
The funny part of this, is that often the "budget" of time / effort is low-balled, and you end up with something that's more expensive to fix. The Hubble telescope from the essay is a great example of this. And we've all seen the project where the decision was to just put in a hacky work around for a mis-design because the project deadline is in less than a month... and it continues that way for over a year. In these…
What is truly criminal is not giving the developers at least a couple refactor iterations to fix all the monkey patch bandaiding put into making that happen. It's a mix of both management's naivete about how bad the underlying code is and their greed of wanting to cash in on the present victory at the expense of future technical debt (that hopefully someone else will have to pay).
I think at least some of this responsibility is on development. They should negotiate and secure the repair iterations for post launch in exchange for making 11th hour design compromises.
There's really one issue here. Budget. You want two pairs of eyeballs on everything as you write it? Okay. Pay two guys. You want complete test coverage? Okay. Can take as long as writing the code itself. Maybe more. You want full documentation? Okay. Guy can't spend as much time on coding. You want new APIs to be included? Okay. Guy's got to read docs and try samples. Less time. What I've seen is you always end up w…
Writing docs and unit tests now is cheaper than fixing bugs later.
I guess you're right that it is about budget because we're all trying to build a spaceship when we're only given some duct tape and a shoebox.
I've been explicitly told in one project to avoid quality and just make something cheap and fast. The project has been in that mode for the last year. Funny how cheap and fast actually means more expensive and slower.
On another project, the manager created different columns in our Kanban board suggesting that we must write unit tests and must have code reviewed and QA'd. Okay Mr Manager, now tell me where in your schedule and budget you're going to fit those key activities when you've accepted a fixed-time, fixed-cost project.
Underestimation is rampant in the industry and I really like this saying in order to justify the necessary work, "If you have time to do it over, you have time to do it right."
We get the software we deserve. Apparently, people aren't ready to spend more money on performance, reliablility and security. When they buy software, they pay the price of a giant ball of mud (if they aren't expecting it to be free!) and they get a giant ball of mud. Simple. You call it insanity, I call it market, supply and demand. Of course, the perfectionists are unhappy about that (being one myself I can certain…
"We get the software we deserve." Painfully true. There are techniques for writing better software. They work. They take longer and cost more. They are not widely used outside aerospace.
There's really one issue here. Budget. You want two pairs of eyeballs on everything as you write it? Okay. Pay two guys. You want complete test coverage? Okay. Can take as long as writing the code itself. Maybe more. You want full documentation? Okay. Guy can't spend as much time on coding. You want new APIs to be included? Okay. Guy's got to read docs and try samples. Less time. What I've seen is you always end up w…
Spending time writing documentation does not mean less time is spent coding, it means less time is spent coding that day, but then that is offset by time gained when someone later has to modify it and can finish sooner, thereby increasing the time available for coding other features.
This article struck a nerve with me because I've been at it 11 years, and feel much the same. The one lesson that has stuck with me most is the quality vs speed paradox: focusing on quality makes you go fast, focusing on speed makes you go slow. The reason is that if you cut corners you are continually wasting time fixing yesterday's cut corners, instead of implementing today's feature. You then feel pressure to rush through the new features to make up for lost time, causing more bugs to stack up, and... In extreme cases the project reaches a virtual standstill, spending all resources fixing past mistakes. Usually that's around the time it gets canceled, no lessons learned, freeing up everyone to do it over on the next project.
So, the issue is not one of budget, but of accounting. You have to account for the future cost of debts taken out on the codebase, and when you do you eventually conclude that the numbers tell you not to take out that debt. Convincing a manager of that however ... well, let me just say that it depends on the manager.
Earlier quoted context omitted.
Middle years if you go into something like management by the time you're 45, I guess. Though I guess you'd have to have planned out that career switch for over 10 years, in that case...
You don't need to plan it. In most companies if you don't fight actively against it, many times also being seen as not wanting a career at all by others, as most of us get pushed into management.