38 ms·

What gets me is that software has been a mainstay of modern business for _at least_ 30 years. And this whole time, every single professional software developer

• bfdm 8y ago
  There is a small subset of devs that will rush and get the work "done" in the underallocated time. The catch is in, of course, the Definition of Done. This is why we spend time aligning teams on exactly this. Sure I can fire off that one line change and tell you it's done. But, does it work? Is it right? Do you care? Typically this sub-par work is done by inexpensive outsourced development shops being managed by a client rep without the capacity to see through the lies until the project goes sideways in the future. The developers who rushed the work are paid and out of the picture and never have to fix the problem or touch that code again, so they don't care.
  • plausibilities 8y ago
    Handyman Contractor mentality vs Civil Engineer mentality in a nutshell Unfortunately not everyone cares about resilience and certain performance thresholds when it comes to construction, especially when budgets become involved. Some customers will are happy to cheap out for a hack-job remodel in the hopes that they can flip their home and run off before the bagholder realizes they got a lemon.
    • Waterluvian 8y ago
      "handyman vs. civil engineer." I'm going to use this the next four or five times and see if the analogy helps. I mean both are valid depending on what you want. Are you asking me to whip up a script to answer a one-off question or a pipeline to answer that question for every customer every quarter?
    • dsfyu404ed 8y ago
      The handyman spends 20min thinking about how to solve the problem. The civil engineer spends 20min thinking about how to solve the problem and 20-days making sure there's no way whoever signs his paycheck is going to be told by a court to pay out a bunch of money if something goes sideways. An professional engineer is basically just a lawyer for the laws of physics. You're not paying for his ability to come up with a solution. Anyone can read the books and do that. You're paying for the fact that other people take that solution seriously.
      • hinkley 8y ago
        There was some CivE professor that people liked to quote who talked about how he had no qualms flunking people from his classes because a degree in Civil Engineering was a license to kill. If you let dumbasses through the system, they will build a pedestrian bridge in a hotel lobby that fails and kills a hundred people at a party.
        • vincnetas 8y ago
          For those who didn't catch the reference : Hyatt Regency Walkway Collapse https://www.youtube.com/watch?v=VnvGwFegbC8 https://www.youtube.com/watch?v=VnvGwFegbC8
      • kjs3 8y ago
        You can not 'read a book' and assess the structural strength of a skyscraper, or a dam across more than a creek, or any number of other things we only trust PE qualified CEs. I hear people claim otherwise, almost exclusively from more or less generally unqualified people who want to diminish the accomplishments of others and claim qualifications don't matter.
  • avgDev 8y ago
    Spot on. I was 1st SE at the company I am at now. Previous applications were developed by outside contractors. I tried making some changes to that code base and found massive issues. Source code was older than the compiled application. Massive methods that were 1k+ lines long. Business rules all over the place in IF statements. Barely any documentation/comments. Only way forward is complete rewrite. I'm a relatively fresh SE, but I read books/research good practices because I'm trying to avoid major mistakes. Also, it is hard to explain to people who even know some code, how difficult it is to make what seems like a simple form. At this point I would refuse to work without time for unit testing/refactoring/research. Interestingly, few days ago I made a very minor change in app I developed straight out of school. App had 0 unit testing and minimal integration testing. It created a bug, because I allowed the specs to change weekly and I just coded it without thinking. Therefore, many lessons were learned that day.
    • adanto6840 8y ago
      I've been a stakeholder in many a "rewrite is the only way forward" projects, though I have almost never actually advocated/voted for a "from-scratch" rewrite. I obviously say this having none of your domain-specific context -- so grain of salt -- but, in my experience, a total 'scratch' rewrite is rarely the right answer. Furthermore, it's often nearly impossible to even be able to ascertain the 'right answer' until you've gained significant exposure to both the application & the business needs; in my experience, you'll have a far better understanding & appreciation of the architecture after a year (or three) of exposure. At that point you are much better positioned to objectively understand the potential ROI (or lack thereof) on a rewrite project vs a more conservative but concerted effort towards incremental improvement over time. When mentoring developers on this general topic, one of the key things that I emphasize is that a functional application (even if substandard in architecture) is already solving a business need and often generating revenue/profit/positive ROI (as the case may be) for what was probably a "[re]write" project at some point in the past. Rewriting is a large undertaking with many unknowns & high costs, often higher than anticipated, and with no guarantees of reaching full functional parity in a given stated timeline. That results in difficult budgeting & ROI calculations (read: risky), and typically means the project itself is risky -- meaning the potential reward would need to be quite large to be worth it & offset the risks. I find that to rarely be the case when you already have a functional application, even if substandard. ;)
  • throwaway55554 8y ago
    > There is a small subset of devs that will rush and get the work "done" in the underallocated time. The catch is in, of course, the Definition of Done. For these devs the Definition of Done is handing it to QA to debug. They do not include all the QA tickets their rush job creates as part of their DoD, and neither does their bad manager. Therefore, it does, in fact, look like they're way more productive than the rest of the team.
    • hinkley 8y ago
      I've worked with devs who were so self unaware that they thought they spent less than 10% of their time fixing bugs in their code. In the end they were right. Because they refused to own their own bugs, everyone else was cleaning up after them. The real problem was when they started using this bullshit ratio to inform their opinions on development processes, pushing back on attempts to mature our process and tools.
  • maccard 8y ago
    On the contrary, there are plenty of devs who won't take on any work until it's been designed, scoped, run through management, prioritised and scheduled, when the actual fix is a one line change that would have taken less effort than the meeting where it was prioritised. There's a happy middle ground between the two, and assuming developers who will deliver quick fixes are all hacks who don't care is counterproductive.
    • hinkley 8y ago
      Those people got burned by managers who like to think that all of their problems are one line fixes that can be rushed out. They think that 'simple' from the user's perspective is 'simple' from an engineering sense and usually those are inversely correlated. Essentially that engineer has grounded the management team. They can't be trusted to behave so their toys have been taken away.
    • commandlinefan 8y ago
      > There's a happy middle ground Yeah, the happy middle ground is a management infrastructure that doesn't insist that you say exactly how long everything is going to take before you start doing it and accept that there ARE unknowns in software development.
    • megablast 8y ago
      Ha, hilarious. I have had changed that were done as soon as they were mentioned, but still required several more meetings to ensure everyone was aware of the upcoming change, had signed of on it (even though it was a severe bug), and discussed it ad-infinitum. Including how to do it, even though I already did it at the start of the meeting. Approximately 100x the time it took to do the work.
      • bfdm 8y ago
        Well, sure. I've had those too. The trick is making sure some of that time is spent validating the assumptions you made explicitly or subconsciously. Doing the change right means making sure that a) your change actually meets the request as the requestor understands it and b) doesn't break other features that already exist.
  • majkinetor 8y ago
    Definition of Done (DoD) does not exist. It is whatever stakeholder needs it to be. Stakeholder might be delusional or not, its your thing to educate or if impossible, avoid working in toxic conditions that future will bring. Everything is a feature: - Automatic tests, a feature. You can buy it if you want or you can accept accidental bugs any time even for stuff that worked before, or even complete meltdown. You don't have to buy them (I personally usually stop working here as this is professionally unacceptable for me, there are tones of sub standard shops that can do this) but accept warnings and give written stuff about it so I can later just ignore your anger with full confidence. - CI/CD - you can buy it, means we are agile and fast, we do 20 deployments a day vs 2 per week where some may fail due to insulin spike at the moment. Maybe you don't want it, and snail speed is acceptable for timeframe/budget or is the least evil. - Epic docs - you can have them or not, again, it will determine how many people you will eventually have in the help desk team, the local IT team, the perceived quality of the system, etc... - Metrics - yes, we can make nice dashboards and you can know FIRST when anybody gets unknown exception or CPU goes higher then 90% but maybe you don't care or don't have a budget and maybe we will spend time doing wrong things.... because we don't know how often are features used... - Full auditing - maybe you need this 10 years back in full detail for legal reason, or NOT because you don't give a damn about it as you plan to sell it in 3. Your decision. and so on and on... Everything is a feature. I wont accept work without some features - I can be realistic if needed but we need to mutually understand and agree what it means for the system and have that written down on public place (for example company ticketing system).
    • bfdm 8y ago
      I'm not sure how any of that relates to you suggesting "DoD does not exist" above. What do you mean? The DOD is not a singular ruleset, but something defined by the project team, and which can evolve as the needs or the project request. It may or may not involve some or all of the components you've mentioned.
      • majkinetor 8y ago
        OK, bad wording I guess. What I meant is there is no universally acceptable DoD even if you pin most of the project decisions. It exists but its dynamic and context/stakeholder/implementator/task/feature specific.
  • dkarl 8y ago
    What's wrong about this is that from the client point of view, Definition of Done ends up depending on who they're talking to more than their situation. Hence the sibling comment of "Handyman Contractor mentality vs Civil Engineer mentality." It becomes a question of identity rather than a question of what the situation demands. I'm not sure how to fix this, but I don't think the problem is as bad in practice as it is in discourse. I don't think people who see themselves on the "Civil Engineer" end of things would do the equivalent of providing CAD drawings and structural analysis for someone who asks them to replace their mailbox. On the other hand, it's still a problem if they talk as if they would.
    • pjmlp 8y ago
      We do. That is why any proper RFP answer already provides a broad overview how the problem would be tackled, and possible solutions to the described problem. Also why during the project development, at various delivery phases, artifacts like architecture diagrams, documentation and UAT from customer team take place.
      • dkarl 8y ago
        It sounds like you're only selecting jobs that require the approach you're accustomed to, which is fine when you get to pick your jobs, but it isn't an option for internal dev teams that work on a product. The jobs come at whatever size they are. If the job is to change a word on a web page, there isn't going to be an architecture diagram, and UAT is going to mean someone reloaded the page and messaged "looks good, thanks!" to the developer. For a consumer product with millions of users, there's probably a checklist of device platforms, screen sizes, browsers, and screen orientations to check that one-word change, but for a SaaS offering with less than 100k users, probably not.
• delinka 8y ago
  You're missing a critical part of the equation: the inexperienced software engineer. Inexperienced software engineers are less expensive, so you can hire more for your payroll budget. These juniors tend to think "yeah, that sounds pretty straightforward. I can do that in a week." It actually takes two months. It takes experience to estimate even nearly correctly. And MBAs love to buy some less expensive, less experienced engineers with their money.
  • shaftway 8y ago
    Or even worse, they actually do knock it out way faster than expected, but it's buggy and unmaintainable. I was that inexperienced software engineer once. At the time a grizzled veteran tried to drop a knowledge bomb on me and said "A good programmer can write about 14 lines of code per day". It took me a really long time to figure out that he had mis-quoted something. It should have been "A good programmer only writes about 14 lines of code a day, they're just the right 14 lines."
    • deleted 8y ago
      [deleted]
    • bluGill 8y ago
      That is an average. On a good day you can write 100, but then you need a week and a half to figure out how to write the next line. New projects are easy, I can write 500 a day for several months before I get to those last hard features that slow me down to 1 a day for a while.
    • DonHopkins 8y ago
      You should also get credit for the number of lines of code you read every day! Some days you read pages and pages of code, but don't write a single line. However, that makes it possible to figure out just the right 14 lines of code to write the next day, by reusing instead of duplicating code that's already there.
    • gubbrora 8y ago
      This is highly codebase dependant ime. The less you have to read and think about wtf is going on the more you can write. And generally the stronger coupling the more you have to read.
• ravenstine 8y ago
  I blame HTML and things like Dreamweaver, Flash, and MS Word in making a whole generation of non-technical folks believe that software development is trivial text-editing and drag/dropping. If "my nephew in high school makes webpages|games|apps" then it can't be all that hard to do, right? Better hire some code monkeys so I can kick back and relax. Hey, why is my assembly line so slow? Yah, mules!
• dsp1234 8y ago
  This isn't all on the non-developers. I've walked into two rooms this week, which contained several senior developers, and when I asked them about non-functional requirements, they had to ask what they were, and why they were important. I've also seen teams where the Defintion of Done doesn't include any steps at all towards deployment. Done is when someone approves the pull request. Not surprisingly, it takes longer for those teams to 'complete' a change. In the former case, they are continuously surprised, and angered, by 'requirements' that 'no one' told them about. In the later, they stop halfway, and wonder why everyone is waiting on them, because it's 'development complete'.
  • dfjhdkjfhsdkf 8y ago
    I agree with your comment about senior devs. it seems as devs climb the ladder many get a superiority complex where they could do things quickly and others cannot. I was once a tech lead of a team where the architect had been berating and criticizing a team member for weeks over something he thought should take a day. I suggested he should take over and complete it. It took him weeks to complete.
    • jimrhods23 8y ago
      "I was once a tech lead of a team where the architect had been berating and criticizing a team member for weeks over something he thought should take a day" As I've gotten more experience as a developer, I've realized that most tasks take longer than I used to estimate..usually because I want to come up with a long-term solution and not just hack something together with no testing.
    • rdiddly 8y ago
      the architect had been berating and criticizing a team member for weeks If berate is truly the appropriate word (upon investigation), and I had any say in the matter, I would fire his toxic ass immediately.
    • funkymike 8y ago
      I'm sure I still have far to go, but currently when I see someone quote a time frame for a change I am more concerned when it is short vs. seems too long. Especially when the dev is questioned and the estimate doesn't include time for documentation, deployment, etc.
• bob33212 8y ago
  Taylorism still exists. The employees in the lower rungs of the organization must be managed by people higher in the org. But when you hire a manager that doesn't understand the work that his employees are doing you get into this situation. The only way to fix this is to have someone who understands the work at the highest levels of the organization. But that is impossible because the organization is designed to hire people without the dev background at the executive level
• _bxg1 8y ago
  It's a failure of education. This is one reason why everyone should have a basic understanding of code: not so they can all become programmers, but so they can get a mental handle on these systems and the people who do program them. It's the auto-mechanic problem; if you don't understand the thing yourself, you have no way to know whether or not you're being taken advantage of. So you tend to just split the difference and maintain a constant, moderate skepticism.
  • collyw 8y ago
    My worst managers have been ex-programers who got promoted to management (too) early. One always seem to think solutions were quick and easy, but that's because he never got to the stage where he could write reliable maintainable code. We were constantly fighting fires and he seemed to think that was normal. I am not convinced that giving people enough knowledge to be dangerous is a good thing.
  • zknz 8y ago
    Why is 'code' different to any other skilled profession - Medicine, Plumbing, Quantity surveying, Piano tuning, Speech Therapy - Why is it essential that 'everyone' knows about code -why draw the distinction?
    • _bxg1 8y ago
      Because like writing and basic arithmetic, it's relevant to some degree in the majority of other fields. Code is used in medicine, quantity surveying, manufacturing, film, oil drilling. It's a field that cross-cuts fields, and decision-makers who don't have a basic understanding of it are going to make worse decisions no matter what their organization's primary focus is.
• dfjhdkjfhsdkf 8y ago
  what surprises me is not that non-developers don't understand that simple changes are not that simple and will take longer than they think to implement. it is that former devs who are now managers don't remember this when they are in a new role. maybe it is the pressure from their superiors to do things quickly or maybe they no longer have the developer mindset
• noego 8y ago
  On the flip side, I've seen far too many teams move at the speed of molasses, for reasons unrelated to the intrinsic complexity of the problem. Bureaucracy, analysis paralysis, no automated testing, accidental complexity, tech debt, poor retention of experienced developers, poor compensation resulting in sub-par hires, insufficient training and mentoring for new hires etc etc. I wouldn't be so quick to assume that every single development team is operating at their most ideal.
  • HeyLaughingBoy 8y ago
    All the more reason to expect it to take longer.
  • sneak 8y ago
    The real trick is being able to tell the difference between a normally slow process and a pathologically slow process, on non-trivial scales. I’m 20+ years in and I’m just getting a handle on it in the last 5 years or so. Meanwhile, I see non-software people putting their complete trust in people with less than half my experience, and getting burned.
    • hinkley 8y ago
      Limited Work in Progress tries to address this. The longer a task takes the more scrutiny it gets from hopefully sympathetic individuals. If you are chasing your tail, after a week or two someone who understands what's going on will unwind you and set you up to complete the task.
  • irq11 8y ago
    I’m dealing with this right now. A team that is downright arrogant about reducing their well-padded schedule, taking months to do a job that should take weeks, at most. Getting them to do anything is like pulling teeth, and accompanied with lots of arrogant lectures about how hard it is to estimate, how you can’t rush quality, and so on. It’s mostly bullshit. This team has historical reasons for their bloated schedules, but at root, they’ve simply been coddled, and never forced to justify their behavior. I’ve been on both sides of the table now. Developers like to gripe and moan about “unrealistic” schedules, but without aggressive pushback from management, a huge number of programmers will simply never ship.
• Udik 8y ago
  I disagree. Sometimes a task requires more time than someone with no knowledge of the system would expect; sometimes it can take much less. I always thought that a big part of my job is to make tomorrow's changes less expensive than today's. If things are constantly costing more than expected, there is a problem.
• everdev 8y ago
  I've been developing for clients for 20+ years and 9 times out of 10 they do under estimate, but I think it has to do with lack of knowledge rather than anything malicious. I found myself doing it when I get quotes for home repair or construction. My mind immediately goes to "I don't think it should take that long" even though I have no idea how to estimate those types of projects. I wonder if it's because with something I'm not knowledgeable about I'm only estimating what I can see, but there are 5-10 tasks that have to happen in the background to make that thing I can see work properly. I just have no idea what those background tasks are to begin with or how many.
  • munk-a 8y ago
    Please don't excuse this, when management over promises and devs "under" deliver, then the axe never falls on management. The best work environments I've seen are where devs and management work together to supply estimates of a reasonable scale and where time is taken in project planning to chop up big goals into small tickets in a developer-meaningful manner.
    • unityByFreedom 8y ago
      Absolutely, it makes no sense for a manager to set timelines without conferring with devs. Devs should set timelines, and business people should set "how much benefit will this bring". The combination of these two things yields priority.
      • munk-a 8y ago
        I agree, and the biggest difficulty that ends up coming out of this fact is that things like paying down tech debt are hard to justify from a business perspective, this is a legitimately hard problem that everyone who ends up in project planning will have to deal with. When you hit it try and rely on talks by experts in the fields and external resources to enlighten the business side as to the value that paying down tech debt will give you.
        • 8y ago
• blhack 8y ago
  >software has been a mainstay of modern business for _at least_ 30 years. No it hasn't. I've worked many jobs where software is still an afterthought. There might be a few software packages that the business licenses for use, but they are far, far, far from every having any software developers on their staff.
  • commandlinefan 8y ago
    Well, what I mean here is - you can’t do business without software (or rather, you can’t do business without computers). I suppose if you’re managing a convenience store in central Alabama you might, but otherwise, software IS the business.
    • blhack 8y ago
      My former company (valuation ~$100M) was not a software company. It was a services company, and most of the business could run off of paper. We were not a convenience store in central Alabama.
• ljm 8y ago
  I see this everywhere when one person doesn’t see the value in the work they’re asking for. It’s not that it takes 4-5 hours instead of 1, it’s that it costs more than they want it to cost, because they only see the output and not the process. Same as you get with designers and artists when a client cheaps out and says their 4 year old kid could do better, or they’ll pay in something other than money. I don’t think explaining it works. I think that’s almost empowering them because they’ve put you on the defensive, justifying your time and expense when it needn’t be justified. Better to get them into the habit of managing their expectations instead of trying to people please.
• hinkley 8y ago
  I bet those MBAs get mad at their mechanic and the guy rebuilding their kitchen every time they go 'over budget' too. The thing is they don't have much power over those people, but they do over us unless we are working as consultants. Some of us wish there were safety codes for software like there are for plumbing and electrical. A lot of arguments reduce to "because what you're asking is illegal".
• ww520 8y ago
  Well the business side wants to squeeze down the cost at any chance they got. I had a client who would say something like "it's a simple change" every single time he made a feature request, no matter how big the change was. And it's been years he's been saying the same thing. It used to rile me up to go into detail on why it would take weeks to get some huge feature done. Now I just double whatever time estimate with him.
• gilbetron 8y ago
  Three months ago I found myself in yet another discussion with a PM about time estimation. I gave him an analogy I use for non-developers, where you try to estimate how long it will take to pack a kitchen into boxes for moving, the catch, I said, is that there's a significant chance each time you open one of the cupboards or drawers there might be a whole other kitchen or even house behind it. He responded with, "well, we just have to figure out which doors have kitchens behind them, that's all!" But during this discussion, I could feel the weight of the countless times I had already had a similar discussion in the past and it was heavy on my soul. Seriously, it feels like we've made no progress at times. Even here, at HN, I've several times brought up the paper "Large limits in software estimation" and been downvoted as not getting it.
  • deleted 8y ago
    [deleted]
  • cutenewt 8y ago
    I've always wondered why we don't provide estimates with a low, median, high scenario. It'd create a lot less disappointment and more accuracy.
    • Consultant32452 8y ago
      Depending on the PM I've found giving a confidence level on an estimate to be helpful. For example on a task I've done a million times I might estimate that it will take me 1 hour with 95% confidence. Other tasks I might estimate at 2 weeks with 50% confidence, same task 3 weeks at 85% confidence. As with all things communication, the audience matters and it's incumbent on the speaker to communicate in a way the audience can understand. So that might not work with everyone. Some of it I think is also personal confidence. If I tell someone it'll take me two weeks, I never budge unless new information becomes available. If you budge, you are welcoming being pressured/bullied into working overtime and/or delivering poor quality all the time to meet infinite demands. Also, we must accept that most customers are willing to accept lower quality/higher risk than we want to deliver. In this case what's important is to state the risks as plainly as possible and set boundaries on what you're willing to do before those risks come back at you.
• sambe 8y ago
  In my experience, well in excess of 20% of devs would make such claims and/or behave like this if given free rein, perhaps even a majority. This is especially true if you take "dev" to mean "anyone who commits code". The exact percentage will of course depend on the nature of the organisation and the incentives set by it. I will give you that eventually they will take a bunch of time on something and have to explain furtively "it's more complicated than you think" but they may not even realise at that point why it's getting harder.
• megablast 8y ago
  > And this whole time, every single professional software developer has been telling every single non-software developer the exact same thing, over and over What? No, not at all.
• rdiddly 8y ago
  More likely those who were paying attention and learned the lesson were promoted, fired, or age-discriminated out of it.
• makecheck 8y ago
  Software prices have not done anything to help with this. Entire operating systems are “free”. Software that takes tons of effort may be $.99 on an app store. We have been programming non-programmers to undervalue everything for those same 30 years. Probably, software packages should never have fallen below $100. The minimum price on any app store should probably have been $10. Then we might see a valued industry.
• james_in_the_uk 8y ago
  If you think software developers get this bad, try being another professional like marketing or legal.
• zxcvvcxz 8y ago
  It's because most software devs are beta males who are unable to express and stand up for their viewpoints. So their concerns get lost.
• vitro 8y ago
  So far analogy that worked for me is a house building one. Something along the lines: If you expect to build a cottage and it turns out to be actually a cathedral, that is the source of the extra time or rework. Or, imagine you build a wall inside a house. But once the wall stands, suddenly you remember, that you wanted to have a window there. Or an electric socket. Imagine what extra work that will be. It is more easy for clients to imagine that and they understand the necessity of planning and a why some changes, although they seem like a small ones, may actually take a lot of time. I have the feeling that software is too abstract to reason about for non developers.
• chiefalchemist 8y ago
  > " then maybe I could understand why they STILL think we’re lying." They think that because occasional something that sounds (to them) as being the same simple request does take and hour or two. That's all they remember. That's all they want to remember. Frankly, short of critical bug fixes, is there ever really a real biz need to deploy such updates almost immediately? Why not say, we expect to have to coded and tested in time for our next scheduled update" or something like that. This way they see the big picture and don't get to know - cause they don't really need to know - the nitty-gritty details. I'm not against transparency. But the fact is, clients need to be managed, as do their expectations.
• ken 8y ago
  Is this unique to software? Our shiny new tunnel took 3 years longer than planned. Our new aircraft are being accused of crashing due to engineering shortcuts to get them in the air faster. A tower crane fell across one of our main streets, killing 4 people, so even if that building was on schedule before, it's sure not going to be now. Is there an industry which can complete all projects on-time and on-budget, with no catastrophes? I'd love to see it.
• drieddust 8y ago
  In my opinion based on limited experience, this is happening because of unrealistic expectations set oy weak CIOs who doesn't have a spine to stand tall. Most CIOs usually leave in less than 3 years so promising moon and delivering Mariana trench is not a problem. IT is just glorified technicians who should live in basement. Business is not willing to share power with IT. This is unwritten class system.