Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Software development is a loser’s game

thehosk.medium.com

Post reply on HN
Print view View original

111–120 of 159 posts

Re: Software development is a loser’s game

#111

Post by danans »

TheCapn wrote: post #104

Is this a safe space to bitch right now? I'm just wrapping up a client upgrade that I quoted 80hrs to do. What my Project Manager heard was "Install will be in 2 weeks" and promised client delivery for that timeframe. What was forgotten was that my changes would take 80 hours, but development doesn't work that way, it never does. What happened is once I cracked the codebase open I found vast chasms of code missing. W…

> What happened is once I cracked the codebase open I found ...

Sounds like giving the time estimate before cracking open the code base may have played a role in this. You (and your project manager) should factor in research time before giving your estimate.

If you are expected to give accurate estimates without research, something might be very wrong with the expectations being put on you.

Re: Software development is a loser’s game

#112

Post by gkilmain »

MattGaiser wrote: post #19

Software developers are just responding to incentives. Managers/Product owners want features and aren't too bothered with defects, as the idea of bugs is so normal now. Do they care about defects? Yes, but only if the cost to fix them doesn't change the deadline.

Yep, totally agree. Writing quality code is always on my mind but when something needs to be delivered yesterday what are you going to do? Options are: delay the release or release it with the crap we wrote

Re: Software development is a loser’s game

#113

Post by hnarn »

danans wrote: post #111
TheCapn wrote: post #104

Is this a safe space to bitch right now? I'm just wrapping up a client upgrade that I quoted 80hrs to do. What my Project Manager heard was "Install will be in 2 weeks" and promised client delivery for that timeframe. What was forgotten was that my changes would take 80 hours, but development doesn't work that way, it never does. What happened is once I cracked the codebase open I found vast chasms of code missing. W…

> What happened is once I cracked the codebase open I found ... Sounds like giving the time estimate before cracking open the code base may have played a role in this. You (and your project manager) should factor in research time before giving your estimate. If you are expected to give accurate estimates without research, something might be very wrong with the expectations being put on you.

If you ask someone to give you an estimate for work needing to be done on your car, not only is it obvious that they will have to look at the car first, it's also obvious that the estimated cost and/or time may and often will overrun (although you're normally notified and asked before it does).

It seems like both of these things should be equally obvious in software.

Re: Software development is a loser’s game

#114

Post by potatoz2 »

terracatta wrote: post #28

> 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.…

I didn't read the article the same way. I think we're all, in a certain way, amateurs, at least in some cases: when we're rushed, stressed, distracted, or all three. As a project accumulates people working on it and, crucially, as existing code is modified and added to, the probability that you'll introduce a bug approaches 1.

I think the article is saying we should focus on tooling that makes natural human errors less likely, instead of trying to focus on writing more code: in other words, write less code, ship it once without errors, instead of writing more code and having to go through the dev to prod feedback loop repeatedly. The tooling that helps you do that are DevOps practices, testing (and testability), simpler/more conservative design, and some time spent thinking about how to construct the software (or reconstruct it, when modifications are needed).

Re: Software development is a loser’s game

#115

Post by TheCapn »

danans wrote: post #111
TheCapn wrote: post #104

Is this a safe space to bitch right now? I'm just wrapping up a client upgrade that I quoted 80hrs to do. What my Project Manager heard was "Install will be in 2 weeks" and promised client delivery for that timeframe. What was forgotten was that my changes would take 80 hours, but development doesn't work that way, it never does. What happened is once I cracked the codebase open I found vast chasms of code missing. W…

> What happened is once I cracked the codebase open I found ... Sounds like giving the time estimate before cracking open the code base may have played a role in this. You (and your project manager) should factor in research time before giving your estimate. If you are expected to give accurate estimates without research, something might be very wrong with the expectations being put on you.

There's more to the story, mostly based on past expectations and experiences. The development I'm talking about is done in a SCADA system, particularly AVEVA's System Platform. For my company we typially have a lot of code re-use through templates so if I see a dropdown box I expect it to be the version that's been used throughout other projects. It shouldn't need testing.

The other half of it was my changes were entirely to the Database and SCADA software, I did not need to touch the PLC software for these features, but I did need to simulate the PLC code to test my new changes. So when it became time to run code in the lab, I found the PLC code was lacking all the proper simulation/test code needed to run it in a lab environment. Basically simulating field I/O such as motor statuses, sensor status, etc. So all that means whoever wrote this project last neglected to include what's seen as standard for our development process and I had to fill the gaps. Its easy to say "this is going to take longer because whoever came before me neglected to test their code" but that doesn't solve the problem we arrived at.

If this was a common issue, I'd pretty much be handing in my resignation, but I'd say this is more of a recent issue where we've taken on too much work for the resources we have. What's happened is coworkers are skipping the stuff like simulation test code because its not customer facing to get to the next project and its not discovered until its too late. If every quote I needed to give included ripping apart every part of the project, even stuff I'm not about to modify, we'd be in a much darker place.

Re: Software development is a loser’s game

#117

Post by [deleted] »

TheCapn wrote: post #104

Is this a safe space to bitch right now? I'm just wrapping up a client upgrade that I quoted 80hrs to do. What my Project Manager heard was "Install will be in 2 weeks" and promised client delivery for that timeframe. What was forgotten was that my changes would take 80 hours, but development doesn't work that way, it never does. What happened is once I cracked the codebase open I found vast chasms of code missing. W…

[deleted]

Re: Software development is a loser’s game

#118

Post by AtNightWeCode »

One problem for me in Software development have been bosses, project managers, product owners, IT architects and so on. Sometimes they get too much power and are allowed to make decisions on how to write software. Bad code can be handled. How to handle software filled with bad ideas is more difficult.

Re: Software development is a loser’s game

#119

Post by justin_oaks »

scottious wrote: post #92
terracatta wrote: post #28

> 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.…

I think you're right, but I also think the author isn't necessarily wrong. Using his tennis analogy, each chunk of code written is like swinging at the tennis ball. You don't have to have the perfect curve-ball, you just have to NOT screw it up. I've too often seen developers try to attack the ball with the perfect swing and the most force possible, only to have it go straight into the net. If they just focused on ge…

This reminds me of advice I give to junior devs who over-complicate things in the planning phase: "Start with the stupidest thing that will work".

You need to make something work before you can make it work well. You need to start simple before you dig into the complexity. Sometimes you find that the "stupid" solution is good enough.

Re: Software development is a loser’s game

#120

Post by justin_oaks »

danans wrote: post #111
TheCapn wrote: post #104

Is this a safe space to bitch right now? I'm just wrapping up a client upgrade that I quoted 80hrs to do. What my Project Manager heard was "Install will be in 2 weeks" and promised client delivery for that timeframe. What was forgotten was that my changes would take 80 hours, but development doesn't work that way, it never does. What happened is once I cracked the codebase open I found vast chasms of code missing. W…

> What happened is once I cracked the codebase open I found ... Sounds like giving the time estimate before cracking open the code base may have played a role in this. You (and your project manager) should factor in research time before giving your estimate. If you are expected to give accurate estimates without research, something might be very wrong with the expectations being put on you.

And the project manager made the mistake of taking an estimate and interpreting it as a deadline.
Post reply on HN