14 ms·

At the end of the day, it doesn't matter what process is used for coming up with estimates and delivering. Regardless of what you think your process is, somewh

• lasereyes136 5y ago
  Welcome to corporate America!
• sirwhinesalot 5y ago
  That is how it goes in the end with any estimate. If it is overestimated the product is delivered with high quality. If it is underestimated the product is delivered with low quality. You can always buy time with technical debt. Our industry always does.
  • willcipriano 5y ago
    I'm in a org that took up a great deal of technical debt, I no longer refer to it as such. It seems to create a false sense of security. Instead I simply call the software what it is, incomplete or unfinished. "We took on some technical debt in Q1." Vs "We didn't finish the project in Q1, but we kinda have something in place that sort of works, as long as you don't look at it funny."
    • panta 5y ago
      Calling it incomplete or unfinished may hide the fact that it is broken, maybe beyond repair.
      • willcipriano 5y ago
        Ive had things like that. Previous to me someone put a large amount of relational data in a object store. It's dog slow and stupidly complex. I call that not fit for purpose, and make it clear that it requires a total rewrite.
        • cudgy 5y ago
          It depends on how often this purpose is needed or called by the system. Tackling debt that is rarely executed can cause other debts to mount.
    • sirwhinesalot 5y ago
      I like the term debt because it makes it clear it is something that needs to be paid off and is accruing interest. Meaning the longer we don't pay it the more expensive it gets, until almost no development time is going to the "principal". Unfinished does not communicate the same. You can have an extremely clean and polished product that is unfinished. You missed the deadline but you're in a good place to deliver future requests.
      • willcipriano 5y ago
        I have found that the sort of "technical debt" that effects customers has another word for it, a bug. Those issues tend to get prioritized quickly. The other kind of technical debt, that has you working nights and weekends because the system falls over in a light breeze doesn't have a special name. I consider "the system is relatively stable" as a implicit requirement of anything you build, if that requirement isn't hit, it simply isn't done. It probably should go back to the team that failed to finish the work, and the PM involved shouldn't get kudos for it's completion as it isn't completed. I think a lot of the problems with software dev could be resolved by being more honest with ourselves.
• wpietri 5y ago
  I agree with you on bullshit dates. But I don't think this part is true: > Regardless of what you think your process is, somewhere near the top of the leadership pyramid, it all boils down to a customer promise upon which hinges your organization's reputation. First, I see the same sort of dysfunctions driven by The Date™ even when no customer promise is involved. Even when no customers are involved. Second, if honoring customer promises were the number one priority, organizations wouldn't make them so casually and without figuring out what is possible. Third, they would use management approaches that make it maximally likely to really hit customer promises, not just in terms of date but features and quality. If I have a date that really matters, I'll aim for first MVP by 50% of the schedule. Then we use customer feedback to iteratively improve every week, so at the deadline we have something polished and proven to satisfy. Fourth, they'd try to hit dates in ways that build capacity to make good on future promises. Instead, the panics I see around The Date™ mean technical debt, strained processes, and burnt-out staff, all of which diminish odds of satisfying promises in the future.
  • Clubber 5y ago
    >Second, if honoring customer promises were the number one priority, organizations wouldn't make them so casually and without figuring out what is possible. I can't tell you how many times I asked, "who came up with this deadline?" and I get "someone in the sales team," or something like that.
    • long_time_gone 5y ago
      The sales team works closest with people who will become customers, it’s not crazy for them to be plugged into a customers needs or priorities. That said, lots of sales people make promises first and figure out the details later which isn’t good business.
      • wpietri 5y ago
        For sure. Any good product balances desire and possibility. Salespeople have a lot of data on desire; engineers on possibility. The problem isn't involving sales. It's not involving the engineers!
• projectileboy 5y ago
  The most bitter pill I have swallowed in my career is seeing the extent to which executive compensation (i.e., bonuses) drive almost everything.
  • corpdronejuly 5y ago
    Ironically understanding that was the gateway to a zen like state of, "Sure but it'll impact our ability to succeed in next Quarters objectives" They do think about those bonuses longer than the next quarter.
• jseban 5y ago
  > Regardless of what you think your process is, somewhere near the top of the leadership pyramid, it all boils down to a customer promise upon which hinges your organization's reputation. Yep, this is exactly how I think about it as well, no matter how hard you try to train people to adapt to scrum with story points, at some level it turns into time estimates and deadlines anyway. So it's always going to be more or less pointless. Even if you do scrum with story points and estimates perfectly, just the fact that it is detached from time makes it useless anyway so it's just wasted paperwork that nobody wants to see.
• ravenstine 5y ago
  > Basically, the PM got accolades, the customer got shitty product, and we hated our jobs. The incentive for a PM or tech lead isn't to help developers do their job well but to make their boss happy. By the developers themselves not being more closely involved with product owners, using a PM as an interface and shield from the rest of the company, they give sole individuals the opportunity to crack the whip for fun and for profit. If a PM is particularly good at what they do, they make everyone believe they are a hero and that nothing would get done without them. Guess who's getting a raise for the project getting done ahead of time? It probably ain't you.
  • jusssi 5y ago
    Just put that "project delivered ahead of time" to your CV and go find the raise elsewhere. That's how the industry works for devs anyway.
    • zoomablemind 5y ago
      ..."ahead of time" does not mean much to me, just that someone at some point was off, maybe some hero projections. On the other hand, "on time and on the budget" means a lot, that all lies got aligned at the end to make it all look like truth - that's a success!
• flerovium 5y ago
  > put a midget in the machine Please don't use this phrase. I'm sure you don't mean it badly, just a reminder.
  • burnished 5y ago
    I got less than I would have expected searching on that phrase. Is 'midget' the problem word here?
    • marricks 5y ago
      I've known a few people less than 5' high and it is never an appreciated word.
    • 8note 5y ago
      The whole phrase is the problem. Impyig that it's okay to put a "midget" in a bad situation to cover your own failings
      • burnished 5y ago
        I thought the point of the phrase was that you had fucked up?
  • throwaway2037 5y ago
    Zero trolling. I'm not here to start a Wokeness Holy War. I understand and appreciate the sentiment of your post. Would it be OK to say "put a little/small person in the machine"? If not, please kindly suggest a better replacement so that we can learn. :)
    • denton-scratch 5y ago
      A demon? Nobody ever accused Maxwell of being unwoke (yet).
      • flerovium 5y ago
• dragonwriter 5y ago
  > At the end of the day, it doesn’t matter what process is used for coming up with estimates and delivering. Yes, it does, because: > Regardless of what you think your process is, somewhere near the top of the leadership pyramid, it all boils down to a customer promise upon which hinges your organization’s reputation. Right. So if the process of coming up with those promises – of what to deliver at what cost in $ and time – isn’t aligned with what goes on below, there is a problem. So, the process below matters intensely. > In non-dysfunctional organizations people at all levels can understand and adapt to curveballs that cause deadlines to slip. “Understanding and adapting to curveballs” in a large organization is itself a matter of process. And a big factor in it is identifying those curveballs with time to understand and adapt. Which is, also, a matter of process, and particularly the processes of estimating, re-estimating, and delivering, exactly the processes you said don’t matter. > The hard thing is it all requires honesty. That is among the hard things, sure. But even before honesty, it requires openness to accepting facts, including facts that have been established fairly solidly about what does and doesn’t work when it comes to estimating intellectual labor instead of implementing rote project management processes derived from physical infrastructure work where the bulk of work is easily-quantified construction, not intellectual labor.
  • winternett 5y ago
    Dev projects often over run their deadlines because customers cram additional requirements into the mix if the relationship isn't carefully managed. I have witnessed several projects that stay in a constant state of billing and extension because everyone is simply comfortable with stable paychecks. An experienced solutions architect and technically experienced project manager are the key to success in mission-critical and time sensitive projects. Company cost cutting is the enemy, whereas roles are under-funded, where interviews are not accountably performed by knowledgeable recruiters and staff. You won't be able to hire and retain efficient and effective staff if you do not properly fund your roles. Attrition is your fault as a manager, not a betrayal from an employee as it's often portrayed. Employees are not indentured servants, they are free people, who can and should always be able to make decisions in their best interests. A company should survive based on it's reputation for delivery and quality, NOT based on it's ability to "underbid" everyone else. Projects fail a lot these days because so many tedious activities to maximize billing hours are conducted and weaved into daily processes by them, because too much attention is paid to padding individual egos and to the ideal of phony "corporate culture" kool-aid. Honesty these days goes a lot farther in meeting goals of project success, AND OFTEN A COSTLY "HOLE IN THE BUCKET" TO YOUR DELIVERY BUDGET. Hire experienced people to lead and mentor teams with a track record of success that communicate well. I have seen entire IT companies overrun with people that don't have a clue about development in management positions... They often win contracts also based on connection to friends elsewhere, but they frequently miss the mark in business, because the staff dedicated to actual delivery is too often a poorly-funded afterthought. Stop hiring people just because they're "your buddy"... If they aren't qualified, competent for, and educated on the requirements of their role, they're "dead weight" towards meeting your project's success goals. Pay each employee well, and hold them properly accountable for their delivery and their attitude, but don't frustrate or work to control/restrict them beyond what threatens the project and productivity of others. Plan religiously for everything to be done within business hours, quit imploring of your employees to put in extra hours. Make sure your contract bid covers proper staffing to not let burnout and attrition become a factor. If delays arise, tell customers quickly, and let them negotiate trade-offs or extensions early and decisively. Hold customers responsible for being reasonable, stop the trend of putting your teams at the mercy of abusive customers. You cannot force a team to subscribe to and uphold Agile Methodology while you yourself as the program director does not uphold your role and responsibilities as well. A manager's primary role is to remove all the barriers to team success. Everyone should be accountable to their roles in a project/company setting... Everyone. A vast majority of project and delay-related problems occur because accountability and physical work is too often only done at the ground level of a company, while the top stays isolated only makes decisions and measures results.
• syngrog66 5y ago
  you just described pretty much the perfect exemplar case for why/when estimates and deadlines are bad. an anti-pattern to be avoided.