Budget as an excuse for poor software seems like a bad argument. There are as many people talking about how much more expensive it is to fix bugs late in the game as there are people pressuring teams to deliver shit code on tight timelines. It costs less to write better software. Invest upfront and rejoice that you did later or rush it out the door now and pay to maintain it forever.
Things I've learned about writing software after 12 years
71–80 of 122 posts
Re: Things I've learned about writing software after 12 years
#72There'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 cases, some sort of unwillingness or inability to pause and be thoughtful, driven by a rush to meet a budget or deadline, cost a lot of money and time. Perhaps, as you suggest, it's the great difficulty of the lay-person or the manager judging the quality of software (or engineering I guess), and naturally selecting for the "cheapest" quality that seems to work, and very often hitting "too cheap".
Re: Things I've learned about writing software after 12 years
#73We 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.
If we're all creating giant balls of mud because the demand is for giant balls of mud done quickly, then we never learn how to craft beautiful software.
It's unfortunate, and it's sad to say I'm often part of it at some level (but I fight it dammit!).
Re: Things I've learned about writing software after 12 years
#74There'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…
In our current society model we don't really have a "choice".
Basically, if the budget is put towards "doing things right" there is very little chance the project takes off, its going to be "too much long term".
Are we doomed to fail? Maybe.
Re: Things I've learned about writing software after 12 years
#75There'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…
This is actually in reply to d--b, who appears to be hellbanned.
d--b, you're hellbanned for some reason. FYI.
Re: Things I've learned about writing software after 12 years
#76There's a sentiment in the article I see a lot that keeps coming up these days: "NASA sent a spaceship to the moon with something 100x slower than my computer, so why does it take so long to load a page"? I think it's entirely unjustified. What makes modern software engineering difficult is that it's one of the few engineering disciplines where not only are you making a Boeing 747 fly, and all the parts were made by…
> 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.
Re: Things I've learned about writing software after 12 years
#77The ideas behind this article are good. The author gives some guidelines that have helped them write better software. However, it makes me think about how we can make "making software" better. It seems like the best current way of going about it is to implement these zen-like self-discipline techniques that have helped the OP. What's so inherently wrong about software? Why is it so damn difficult to write software th…
this is what i think
http://productionjava.blogspot.in/2014/12/why-is-it-difficul...
Re: Things I've learned about writing software after 12 years
#78Earlier quoted context omitted.
> but you're also replacing the engine in flight! Could you elaborate that, using a mainstream example, please? > Also the specs on the parts are kind of spotty. ... Are you referring to the moving parts of the Internet itself? > There are layers upon layers of abstraction, and no one knows all of it. No one even knows most of it. In fact, most people don't care about any of it other than a cubic centimeter of their…
I have to disagree with you. The root problem is not that people are undisciplined, but that the problem is undefined. Take the time and effort to do things in a verifiable and provable way is useless if the solution is the wrong thing. The biggest risk in a startup is to take some investment money and build something which doesn't lead to any kind of user traction or revenue stream. That is such a big risk that it's…
> The root problem is not that people are undisciplined, but that the problem is undefined.
> If and when you find a real business idea then you can rewrite the code with the knowledge of what it needs to be genuinely useful.
I have seen several start ups - invested in a few, contracted for several more - of the nature that you describe.
With the benefit of hindsight, what is there so very laudable (thanks Jane Austen) about a culture that does not have a `real business idea', but `rushes to take some investment money and build something'? When you start without a clue of what sustainable value you can provide, most of your problems are invented problems.
Another thing while we are on this topic: it is exceedingly rarely that a start up really loses out because another beat it by a few weeks. Yet, shoddy work is encouraged or condoned in the name of the necessity to move at `Internet speed'.
The `real business idea's of most start ups offer little incremental or differentiating value. The ratio of successful start ups to the unsuccessful ones speaks volumes!
Re: Things I've learned about writing software after 12 years
#79There'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…
It's been tried over and over again. Throwing developers at a project has negative returns at some point.
The truth is that individual engineer skill is the only good bet, and only if within a culture that works.
Re: Things I've learned about writing software after 12 years
#80Earlier 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.
Is there a high level overview somewhere I can read? Don't even know what to google here.
Search for high integrity software.
For example, with MISRA it may be C, but feels like Ada.
Or Spark similarly for Ada