61–70 of 129 posts
>Why does my engineer say it will take a month?
if you don't know the answer to that, you're a bad manager. Either you hired bad engineers or you have no idea how your dev process works.
I have cleaned up too many messes because of negligence from people who do not understand how hard programming actually is. That's what most people, especially us developers at times, fail to recognize. That 5 minutes someone took to write an "easy" query against the CI and deployment server almost brought it down (true story, luckily I was monitoring it look at another issue).
The ability to write code is taken for granted, because anyone can learn it. Some programming is easy, and some is extremely difficult and the real trick is knowing which. What scares me most about the code being written are the one off queries, etc. The ones that will "only be used once" or "only for low transaction instances". That's never true, someone will always have it laying around for that time when "we just really needed to make that update".
An old boss of mine used to say "the perfect is the enemy of the good." This is true, there are a number of times you need get something up and running and worry about fixing it along the way. There are other times when that "good little app" got used in the wrong way and cost us hours of downtime because of a mistake due to rushing. Now the perfect solution doesn't look like it was such a bad choice after all. I can wait a day or so for a query that I could write in 5 minutes. In the long term, waiting a few extra hours isn't going to impact anything that much. I'd rather the developer be through then explain why no one went home that night because we had to clean up a mess.
Earlier quoted context omitted.
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.
seems often developers tend to over engineer or focus on edge cases that inflate costs, and not given enough attention to ROI
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.
On the flip side, when something DOESN'T need HA, sub-millisecond query response time, or lynx and IE Edge compatability, people need to know when "good enough" is good enough. On my ops team, we've gotten some flak for not building robust enough of a request queue for some tasks. But it's been down several hours in the past year. The server almost never needs maintenance. None of the workload is real-time. App resta…
Ah! Classic duct tape programming!
Something like this is fine as long as the requirements don't change.
But we all know that at a point the requirements will change. And then you have to tell your customer that the "little new requirement" can't be accomplished with a cheap little change but requires instead a complete rewrite that will cost even more then the previous system did.
The only question is whether you are a honest company that told the customer before that that will most likely happen in the future or your planed for that inevitable outcome in the first place...
Earlier quoted context omitted.
Kind of. There are a few people who I don't mind using tools as soon as I have even a minimum functionality working. Then we have a few people who completely ignore any limitations I put of tools and use them in ways in which they are explicitly not working. Case-in-point: I created a process that automated a particular task. Said task bears a resemblance to another task, but there are a lot of edge cases in the othe…
Maybe it's a false economy to automate other processes if the political fallout from not automating hers is big?
I'd say that my boss generally makes the right decision when it comes to what is best for the organization, and I'm not in the habit of rewarding people for being abusive.
Earlier quoted context omitted.
Okay, that sounds pretty cool. S3 can host static HTML files?
Yes, I host my blog that way: - Generate static files using Pelican - Dump the files to S3 - Set up Route53 to point a domain at the bucket - Set up CloudFront (Amazon's CDN) to sit in front of the S3 bucket, since I found pure S3 to be too slow Works incredibly well.
Earlier quoted context omitted.
Okay, that sounds pretty cool. S3 can host static HTML files?
Yes, I host my blog that way: - Generate static files using Pelican - Dump the files to S3 - Set up Route53 to point a domain at the bucket - Set up CloudFront (Amazon's CDN) to sit in front of the S3 bucket, since I found pure S3 to be too slow Works incredibly well.
On the flip side, when something DOESN'T need HA, sub-millisecond query response time, or lynx and IE Edge compatability, people need to know when "good enough" is good enough. On my ops team, we've gotten some flak for not building robust enough of a request queue for some tasks. But it's been down several hours in the past year. The server almost never needs maintenance. None of the workload is real-time. App resta…
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.
Earlier quoted context omitted.
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.
seems often developers tend to over engineer or focus on edge cases that inflate costs, and not given enough attention to ROI
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.
Earlier quoted context omitted.
I had a veteran DBA close to retirement (she was my cube-mate) warn me about this when I was an intern. I had a very simple request come in to update some data. Didn't even take 5 minutes. She told me: never do the simple tasks immediately. Sit on them for a bit. Business users don't understand complexity of different tasks and think they should all take the same amount of effort. So, if you do one thing in just a fe…
I heard a story from an ex-wall-street engineer who related he was once asked to fix a message passing system so that it could now pass something like 10 x as many messages per second that before. He rewrote it and it now passed 1000 x messages / sec. He almost turned it in that way and then realized he was undercutting his future self. So he backed off the improvements to the required 10 x. Sure enough he got a big…