4 ms·

Regardless of what organizations claim to be looking for, virtually everywhere I've been besides my current position has been staffed to the brim with junior de

by stouset 11y ago

Regardless of what organizations claim to be looking for, virtually everywhere I've been besides my current position has been staffed to the brim with junior developers, and been in dire need of at least a few people with seniority. The irony is when a senior person does come in, all their recommendations are ignored because they will slow down the pace of development. Which it will, but in exchange for setting a sustainable pace of development. A senior developer might (making numbers up here) crank out 100 lines of code per day, but a junior will crank out 1,000 while solving twice as many business problems. Unfortunately, bug counts seem to scale linearly with code size, so most of the problems you're solving are actually just a direct consequence of the ten-fold increase in bugs in the larger code base. Eventually progress grinds to a complete halt as it becomes too difficult to add business value, and the company enters zombie mode where its death is virtually inevitable, but can still operate for years through additional funding. Sorry, I may have gotten a little off point there.

crdb 11y ago
Don't forget that bug count is actually a KPI. More specifically, you end up with JIRA ticket inflation: you get exponentially more tickets generated with time, but the value of each ticket decreases in proportion. The CEO of the business will basically hear two messages: 1. "Look at how well my tech organisation is doing, we solved 150 tickets this week, a 40% increase over the last 3 months! And yet our headcount only increased 10%." 2. what your comment said. It's down to him to act accordingly. I've seen many trust 1, he's "data-driven". There's variations of the JIRA ticket inflation, such as requesting regular update meetings and the tech organisation adapting by finding days-long tasks and pushing off the hard weeks-long ones (since they do not result in neat weekly progress updates). "I've listened to all the excellent argument for doing nothing, and reaped the consequent frightful harvest. I've watched people hop up and down and call it progress." - George Smiley (in Smiley's People) making the point that this is not a new problem.
EliRivers 11y ago
Sweet Jesus, so true. Every time someone suggests we have proper requirements or decent testing or put some thought into design or rewrite something that's causing endless trouble, we're told there's no time for it. Which is how we're now up to "release candidate" FORTY, four months behind the original release date. Because tests get done six months after the code was written, whatever doesn't fail has a fifty-fifty chance of not actually doing what's needed (so it's a bug), and testers and coders have long conversations about "what's it even meant to do, anyway?" that are unanswerable because there is no requirement or design reference. The cost of running four months over schedule thus far is, well, four man-months multiplied by the number of employees, basically. So yeah, excellent savings compared to having spent a couple of days thinking about what we're trying to build and having testers involved throughout rather than just dumping six months' worth of untested development on them (and expecting them not only to be able to test it in a week, but expecting everything to pass). Wouldn't mind if this was the first time, but EVERY DAMN CYCLE is the same. We can't possible start doing things properly, look how far behind we are! It's like there's a mental gap, some kind of inability to see the cause and effect right in front of their faces. ( Morale is low :p )
- wpietri 11y ago
  > Every time someone suggests we have proper requirements or decent testing or put some thought into design or rewrite something that's causing endless trouble, we're told there's no time for it. I should point out that as professionals not only do we have the option of saying no to bad requests, I think we also have the obligation to do so. I know there's this culture in software development of "just do whatever the bosses say", but as far as I can tell it's not a law. I've told executives no on many occasions and so far I've never been fired for it. At first their startled, but if you keep saying no to the bad requests and help them understand what they're supposed to do, they eventually come around. And if not, this is an excellent time to find another software development job. > It's like there's a mental gap, some kind of inability to see the cause and effect right in front of their faces. Yes, that definitely happens. Until people experience it the other way, they often think that's just how software development has to be.
  - EliRivers 11y ago
    "I should point out that as professionals not only do we have the option of saying no to bad requests, I think we also have the obligation to do so." Indeed. I watched three people say "no" to a significant, new piece of very important software that replaced completely our legacy data storage/fetching/processing methods. They said "no" for the reasons you'd expect; not properly specified, unreasonable expectations of basically magic on the part of management, very improbable timescale. In one meeting, when a very skilled programmer (who goes to the C++ committee meetings and that sort of thing) said "no", the response was "Well then I'll find someone who can." What they got, of course, was someone who didn't say "no" (and of course, there's an element of self-selection here; given that some skilled, competent software engineers said no, the person who said yes was, harsh as it may sound, an adequate programmer but an incompetent software engineer). What we got was a total car crash of software, six months late, that's massively unsuitable, doesn't do what's needed, undocumented, untested, everything bad that you'd expect. A great deal of the 40 "release candidates" were desperate fixes to this car crash, that our recently appointed new software architect is planning to take outside and execute in the car park as soon as we get a "release". So that was a great use of a year. Where this is going is that saying "no" didn't actually stop them finding someone who wouldn't say "no". On the plus side, the person who delivered this truly atrocious software to us is now actively looking for another job. Not that he was fired, no no, but he's now got zero credibility and nobody wants to work on anything he ever touched. Christ, I wish I'd just gone into mathematics.

by stouset 11y ago

crdb 11y ago

Don't forget that bug count is actually a KPI. More specifically, you end up with JIRA ticket inflation: you get exponentially more tickets generated with time, but the value of each ticket decreases in proportion. The CEO of the business will basically hear two messages: 1. "Look at how well my tech organisation is doing, we solved 150 tickets this week, a 40% increase over the last 3 months! And yet our headcount only increased 10%." 2. what your comment said. It's down to him to act accordingly. I've seen many trust 1, he's "data-driven". There's variations of the JIRA ticket inflation, such as requesting regular update meetings and the tech organisation adapting by finding days-long tasks and pushing off the hard weeks-long ones (since they do not result in neat weekly progress updates). "I've listened to all the excellent argument for doing nothing, and reaped the consequent frightful harvest. I've watched people hop up and down and call it progress." - George Smiley (in Smiley's People) making the point that this is not a new problem.

EliRivers 11y ago

Sweet Jesus, so true. Every time someone suggests we have proper requirements or decent testing or put some thought into design or rewrite something that's causing endless trouble, we're told there's no time for it. Which is how we're now up to "release candidate" FORTY, four months behind the original release date. Because tests get done six months after the code was written, whatever doesn't fail has a fifty-fifty chance of not actually doing what's needed (so it's a bug), and testers and coders have long conversations about "what's it even meant to do, anyway?" that are unanswerable because there is no requirement or design reference. The cost of running four months over schedule thus far is, well, four man-months multiplied by the number of employees, basically. So yeah, excellent savings compared to having spent a couple of days thinking about what we're trying to build and having testers involved throughout rather than just dumping six months' worth of untested development on them (and expecting them not only to be able to test it in a week, but expecting everything to pass). Wouldn't mind if this was the first time, but EVERY DAMN CYCLE is the same. We can't possible start doing things properly, look how far behind we are! It's like there's a mental gap, some kind of inability to see the cause and effect right in front of their faces. ( Morale is low :p )

wpietri 11y ago
> Every time someone suggests we have proper requirements or decent testing or put some thought into design or rewrite something that's causing endless trouble, we're told there's no time for it. I should point out that as professionals not only do we have the option of saying no to bad requests, I think we also have the obligation to do so. I know there's this culture in software development of "just do whatever the bosses say", but as far as I can tell it's not a law. I've told executives no on many occasions and so far I've never been fired for it. At first their startled, but if you keep saying no to the bad requests and help them understand what they're supposed to do, they eventually come around. And if not, this is an excellent time to find another software development job. > It's like there's a mental gap, some kind of inability to see the cause and effect right in front of their faces. Yes, that definitely happens. Until people experience it the other way, they often think that's just how software development has to be.
- EliRivers 11y ago
  "I should point out that as professionals not only do we have the option of saying no to bad requests, I think we also have the obligation to do so." Indeed. I watched three people say "no" to a significant, new piece of very important software that replaced completely our legacy data storage/fetching/processing methods. They said "no" for the reasons you'd expect; not properly specified, unreasonable expectations of basically magic on the part of management, very improbable timescale. In one meeting, when a very skilled programmer (who goes to the C++ committee meetings and that sort of thing) said "no", the response was "Well then I'll find someone who can." What they got, of course, was someone who didn't say "no" (and of course, there's an element of self-selection here; given that some skilled, competent software engineers said no, the person who said yes was, harsh as it may sound, an adequate programmer but an incompetent software engineer). What we got was a total car crash of software, six months late, that's massively unsuitable, doesn't do what's needed, undocumented, untested, everything bad that you'd expect. A great deal of the 40 "release candidates" were desperate fixes to this car crash, that our recently appointed new software architect is planning to take outside and execute in the car park as soon as we get a "release". So that was a great use of a year. Where this is going is that saying "no" didn't actually stop them finding someone who wouldn't say "no". On the plus side, the person who delivered this truly atrocious software to us is now actively looking for another job. Not that he was fired, no no, but he's now got zero credibility and nobody wants to work on anything he ever touched. Christ, I wish I'd just gone into mathematics.