Exactly, this is the substantial other side of the argument that almost always seems to be left out of the discussion.
"Good enough, done in a week" is a perfectly viable option that is rarely offered by timesheet-padding developers.
"Good enough, done in a week" is a perfectly viable option that is rarely offered by timesheet-padding developers.
I see it all the time from timesheet-padding developers who also are in a position that they'll benefit from the higher long-term support costs that that approach generates.
It's just a matter of whether they want to pad timesheets in the short term or the long term.
Or are you referring to some sort of government bureaucracy dealing with loosely coupled contractors bidding on jobs?
Back on earth I can tell you full time devs at big 4 tech companies padding estimates would be a very difficult thing to pull off, for a variety of realities.
Same situation for many other developers.
I was responding to (as should be clear, since I quoted it) an upthread generalization about what “timesheet-padding developers” would or would not do. It's expressly not a statement about developers generally.
> Back on earth I can tell you full time devs at big 4 tech companies padding estimates would be a very difficult thing
And pointless, since they aren't paid hourly. Timesheet-padding is only incentivized when developers are paid (or work for a company that is paid) based on timesheets, that is, hourly.
But, anyway, I wasn't talking about padding estimates, that was the poster I was responding to. My observations was that developers with incentive to pad timesheets often will do the opposite of padding estimates, going for quick and dirty development solutions which create more maintenance and support hours (of course, that only occurs as a result of structural incentives where the contractors building the system or feature also expect to be supporting it, but that's often the case.)
manager: Why did you allow this thing to happen.
me: It was an edge case that I pointed out 7 months ago. I've put it on the backlog 3 times, and you've removed it each time citing that it's an edge case that would never happen, and other newer features needed to be implemented.
manager: That's an engineer's response. Just fix it!
me: welp, shrug
Translation: I didn't actually require any answer other than "I am sorry, sir/ma'am, it will never happen again." Facts are irrelevant. I may not always be right, but I am never wrong, code monkey.
In certain cases I've also overridden the "ignore that for now" in favor of at least some minimal fix because part of my job is to give you what you don't know you need to ask for, not just exactly what you ask for. And there's the value add because compared to people who don't consider that part of their job, my stuff / my team's stuff works better out the door.
Another similar question that I've noticed others not always asking are things like "how often would this be used again, is it just a temporary one-off" which, of course, has an answer that's subject to change, but at least guides the initial design. And when it changes it gets revisited.
This is a two-edged sword, though. I agree it's best practice from a technical point of view, but enabling wilful ignorance on the part of someone above you in the chain will eventually lead to a showdown when you really do need a week to fix it and it really is critical, and they tell you not to, and they'll stick to their guns because (as far as they know) they've been right every time.
Yeah, pushing that too much requires either (a) sufficiently-padded early estimates so it's not a slippage and a nasty surprise (a good practice anyway, but hard), or (b) a sufficient level of don't-give-a-fuck, or (c) really good judgment around "when this is necessary to give them what they need vs what they want" and when not to e.g. truly critical and immediately messagable stuff.
A healthy dose of don't-give-a-fuck/willing-to-say-no is often a good thing anyway, though, if you're able to do it politically/smoothly enough :)
I worked at a hedge fund for 9 years in back office IT developing firm-critical software. We traded pretty much anything you can trade, so we had a lot of trading desks requesting changes all the time. So, while making a change for one desk, at least one other is bitching about why their changes is taking so long. Yeah, the change might only take 5 minutes, but it might be 4 weeks before I get to it.
We traded for all but about 2 hours of the week. Means you had a narrow deployment window. Even once the change has been made and tested, you've got to wait for the deployment window. One weekend of each month was off-limits to system changes to options expiration. So, even the smallest, simplest change might take at least a week or two to get into production. Quite longer big or breaking changes. Toss in regulatory and compliance issues and you've got a lot of paperwork and sign-offs to do a deployment. You've got to track those people down, explain the changes to the managing director and the risk with making the change.
Emergencies were fun. Either getting called or having to call a manager at 2am in the morning to get approval... I once had an emergency at 11pm. I got a call from my director about 15 minutes after I'd popped sleeping pills (I was having insomnia at the time). I went through every source of caffeine I had in my apartment to get through that; I dropped off the conference call at 4am. I recall hearing the call went on for several hours afterwards.
TL;DR It's not always over-engineering, it's more often misunderstood or invisible (to the business side) pressures on the engineer's time.
Which itself could be a result of management often viewing engineering as a cost center with no perceivable ROI. This can be reflected in pay not being commensurate with company performance and not stacking up to other employees (sales, management, etc.) and gives the engineers no reason to pay attention to ROI in their decisions. I would bet that in companies where engineering is very much involved with cost, ROI, and paid based on how those numbers turn out, the engineers would focus less on edge cases and know when to draw the line.
Funny this story reminded me of a recent event where my team was working on some reg-ex expressions for a language processor. Not overly complex stuff but not simple by any definition (they had been working on the set for 2 days), they had a side line manager from another department, that knew enough to be dangerous, so he decides he is going to run in his office and whip up some reg-ex, after reading the docs. So we threw it in the test cases, after tons of failures he got the picture that edge cases count, as he got a good visualization of how multiple edge cases increase the the odds of failure by orders or magnitude.
What's hard is finding the right balance. The proverbial "SQL in 5 minutes" moment from the blog post may not fully appreciate the developer's job, but it can serve as a reality check to self-question if you're over-baking it.
If you're willing to come in on the weekend to fix your query, be my guest. But I like being able to spend my weekend relaxing.
They often blame others while finding very sneaky and specific ways to, despite all odds, rise to a relatively insulated level without any modicum of technical or managerial prowess
congrats!!!
Damned if you do damned if you don't.
If you don't focus on edge cases then later it's your fault for being sloppy.
If you focus on edge cases you are "over engineering".
Most of the time "over engineering" just means "I wish this was cheaper".
15 years with software dev experience and every single dev team at midsize and larger companies has always asked for far more time than necessary. Same with almost all enterprise consultants.
Or did you not give them the time they asked for and declare yourself correct after squeezing in a deadline? And if so how do you know what corners were cut or what technical debt was accrued to make a deadline the team did not sign off on?
Whether every single person is noble is irrelevant. People are making broad generalizations here against the reputation of developers with what I see to be weak and anecdotal evidence.
If someone has made serious inquiry into the subject and controlled for complexities like I suggested above then by all means let the chips where they may.
This is human nature, people will look out for themselves. Many, if not most, are looking to do the least amount of work in return for the largest reward, and it's very easy at bigger companies to pad hours, compounded by bureaucracy and poor management. This is seen in many other professions amongst all types of people, nothing specific to software.
Could I do the work myself in a week? Yes. Can I assign it to a team of diverse junior to mid-level developers and expect them to do it in a week as well? Realistically, no. They have to investigate, acquire knowledge, work together, be guided on the correct design (or get to it themselves), and then finally do the work and test it to sufficient quality.
Even more so the case if it's tech we have not worked with before.
This is my concern. It absolutely doesn't give you that knowledge. Accurately estimating development of non-trivial software is still an open problem. The best solution we have to date is to accept this fact and use it in our process and planning to our advantage when possible.
If the work you're talking about is rote and mostly a matter of repeating a pattern rather than innovating and engineering, sure I can see that being more predictable. Unfortunately quite a bit of software development does not fall into that bucket.
As for personal experience, well over two decades in the business, if we're keeping score.
So, you would have readers believe that developers are egoless automatons who do everything by the book? If true, they'd be the only faultless profession on the planet.
I don't blame him for that part - it doesn't take much complexity before any manager is incapable of understanding every detail.
The scary part is he doesn't seem to understand the fact that this implies the most successful teams will utilize some degree of trust and efficient communication to deal with this reality.