15 ms·

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 w

• plausibilities 7y 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 7y 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 7y 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 7y 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 7y 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 7y 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.
    • gmueckl 7y ago
      A lot of the most serious software engineering work that I have done had much the same ratio: coding the a solution that mostly works was easy. Making sure that it is robust against all kinds of failures (CPU, RAM, bus/external device failure, random bit flips etc.[0]) and does the right thing was a lot of work. [0] The system I worked on was hardened against all of that and some more failure modes.
• avgDev 7y 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 7y 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 7y 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 7y 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 7y 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 7y 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 7y 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 7y 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 7y 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 7y 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 7y 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 7y 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 7y 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 7y 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 7y 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.