7 ms·

That last one about the guy who tucked away 2 extra mb of memory for a rainy day is one of the most bad ass things I've ever read about a programmer (never thou

• netcraft 12y ago
  I came across code in a legacy web application one day, on a page that was probably the most used part of the application that was really nothing more than sleep(1000); I went through the version control history and found that is was a previous employee that would go in periodically and lower it any time he wanted to act like he had been working - he had started around 3.5 seconds. Which reminds me of being a kid and mom telling me to turn down the tv - I would "accidentally" hit the wrong button and turn it way up for a few minutes, then just turn it back down to where it was.
  • rqebmm 12y ago
    I first heard of "The Speed Up Loop" here: http://thedailywtf.com/articles/The-Speedup-Loop http://thedailywtf.com/articles/The-Speedup-Loop
  • nostrademons 12y ago
    This is a pretty common sales & negotiation technique. Anchor high, with a much higher profit margin than you actually need. Do your best to get the customer to buy at the high price. Periodically, when you want to seem benevolent, offer a "sale" or "concession" that gets you down to what you were willing & able to do in the first place. Every time you buy stuff on sale at the grocery store, you're seeing it in action, but you probably don't think much about it.
  • 3pt14159 12y ago
    If I ever found out someone did this not only would I fire them, I wouldn't keep it a secret. I'd make sure everyone on the team knew exactly why he was fired. That is acting is gross bad faith. Think of the time it had cost all those people around the world just because he wanted a day off here and there. Blows my mind that someone would do that.
    • netcraft 12y ago
      With my example I agree with you - the example in the article is different though - putting artificial constraints into a project to encourage innovation and making sure you have the necessary resources - and then removing the constraint before you go live - isn't a bad idea IMO, especially when you are dependent on multiple teams. Think of it as resistance training :)
    • samspot 12y ago
      Not to defend this practice, but I heard a story about a whole team who put in a sleep that would automatically shrink over the first 6 months it was in production.
    • pc86 12y ago
      I understand where you're coming from, and I agree with you, but we can't pretend that 1 second from 10,000 people is the even close to the same at 10,000 seconds from 1 person (or really anywhere in between). The entire concept of "we saved 10 million hours of productivity by shaving 1.8 seconds off this process" is bunk. You saved 1.8 seconds of productivity n million times, which adds up to not a whole lot of extra productivity. Put another way: Whether $APP takes 0.1 seconds or 1.9 seconds to do something does not at all change what time I'm leaving at the end of the day.
      • Swizec 12y ago
        > Put another way: Whether $APP takes 0.1 seconds or 1.9 seconds to do something does not at all change what time I'm leaving at the end of the day. But it does greatly change how annoyed you leave at the end of day. Not to mention any noticeable delay in load times will quickly get people to start multitasking, which can easily change a 2s delay into a 2min delay. This can easily ... well it does make a difference. I noticed this mostly while testing code. After clicking through the interface many times it can easily add up to an hour less actual work getting done that day.
      • sunfish 12y ago
        User behavior when interacting with a program that responds in 0.1 seconds is drastically different than with a program that responds in 1.9 seconds; see [0] [1] etc. I agree it's not very meaningful to just compute the total number of seconds saved, but on the other hand, the productivity gain could easily be far greater than what that number suggests too. [0] http://googleresearch.blogspot.com/2009/06/speed-matters.html http://googleresearch.blogspot.com/2009/06/speed-matters.htm... [1] http://www.webperformancematters.com/journal/2007/7/10/acceptable-response-times.html http://www.webperformancematters.com/journal/2007/7/10/accep...
  • anotherevan 12y ago
    I just recently heard a story that went the other way. An engineer of elevator systems would spend hours doing all his calculations by hand, vowing it was too complicated and important to trust to a computer. (Yeah.) The programmers in the company assured him they could write a program to do the calculations for him, which they did. He never trusted the results though, insisting that the program was not producing correct results. One of the programmers realised that he didn't trust it because the program spat out the results almost instantly. It was too fast, it had to be wrong. So he stuck a twenty second sleep in before the output, told the engineer he found the problem and fixed it. The engineer now felt the results were correct. (Aside: I don't think I would want to get in a lift designed by an engineer who intuits the correctness rather than verifying the math, but I thought it was an interesting little parable on user interface design.)
    • murbard2 12y ago
      Kayak does this when looking for flights. The results are instant, but by taking more time, it's giving the impression that it's trying really hard.
      • sre_ops 12y ago
        Nope. It goes to origin on every hit.
    • jumanji 12y ago
      Relevant discussion on the UX Stack Exchange: http://ux.stackexchange.com/questions/41682/pros-cons-of-splash-screen-with-articifial-loading-delay http://ux.stackexchange.com/questions/41682/pros-cons-of-spl... (which also links back to a story on HN about a locksmith.)
    • cafard 12y ago
      That sounds a bit like the cake mix people who discovered that they got better sales if the mix required an egg to be broken and beaten into the mix. The taste was no different, but the cooks felt better. Or the antiseptic spray that added a component to give the sting consumers expected.
• gaius 12y ago
  he was toasted as the hero of the project. Sorry, but this guy sounds like an asshole. Derailing a project so you can be the one to save it is pretty sleazy. What about the stress on his colleagues, the late nights, etc? They were "frantic" and "exhausted", and he was sniggering the whole time. The human cost of his moment of glory?
  • delucain 12y ago
    They still only came under budget by half a MB. That stress they put into reducing it was very likely still entirely justified. It's like setting your alarm clock 10 minutes fast to hurry you out the door in the morning. Taking credit for the last 2MB is a dick move for sure though.
    • FreezerburnV 12y ago
      But is it really a jerk move? He had the foresight to tie up those 2MB at the very start so that later on it could be removed. And in the scenario written about, doing that ahead of time saved the project and major content from being cut.
      • pc86 12y ago
        Yes, it is.
      • sago 12y ago
        Yeah it's a jerk move. Think what would have happened if he hadn't added the alloc. The team would have been in the same situation, would have busted their guts, got it down under budget and slapped themselves on the back. They might have got it down earlier too: who knows how many person hours got wasted on the last 384K of savings that were never needed. Think what could have happened with the alloc: the team is hovering around 3-4MB above budget and running out of ideas, with major efforts shedding only a few tens of KB each. They agree they might manage to cut 1-2Mb with a herculean effort, but 4? No way. So with the deadlines approaching decisions are made to cut some feature or content to avoid failing TRCs or missing contracted delivery dates. If you have to get it down under target or cut something else, then I can't think of a single situation in which having an artificially low goal will help you. At the very least, the fact that the team thought this guy somehow helped them ship rather than adding to their problems and lauding it over the actual engineers who'd bust their ass to make the savings, is a huge jerk move.
• tunesmith 12y ago
  Back in the early 90's when I was in college and everyone had email accounts on shared unix servers that they'd log into, a sysadmin friend would oftentimes notice that the disk would be getting close to full. He'd start a process that would slowly fill up disk space, and wait as all the other logged in users would realize they could no longer save files - then they'd frantically start to delete files they no longer needed. After a while he'd cancel his process and the system would have a lot more space.
  • rgj 12y ago
    The other way around: In 1995 I worked in a Dutch research institute where the file server was always almost out of disk space. Whenever some space freed up, my manager used to create something he called a 'balloon': a directory with 20 files of 5 MB each (which was huge back then). If the disk was full and we needed space, he just removed one of those files and we could quickly write our files.
    • Gravityloss 12y ago
      tragedy of the commons... or is it comedy?
      • cunac 12y ago
        it is more that people today take for granted huge amount of resources at their disposal you become VERY creative when hard times hit :-)
        • jacquesm 12y ago
          You only become creative when faced with limitations.
          • pbhjpbhj 12y ago
            Is boredom a limitation?
    • 12y ago
• jandrewrogers 12y ago
  When designing performance-sensitive software, database engines in my case, it is not uncommon to "bank" optimizations and resources for future code emergencies. From a customer's perspective, you are always allowed to make the software faster with a future patch but never slower. The issue is that sometimes you find bugs (or add/complete features) where the correct implementation is somewhat slower than what you already shipped or planned for. In these cases, you end up creating two patches: one to address the customer issue and one to add an optimization to return the overall system performance to its prior level. I've shipped complex v1.0 software where low-hanging optimizations would probably have made the system 2-5x faster (though still perceived as being extremely fast). Over time, it allowed us to add in expensive features and bug fixes without perceptible reductions in performance by harvesting the optimizations we'd banked in the first version.
  • nvader 12y ago
    I learned something from this. I'm saving this snippet of advice for future reference.
    • 6footgeek 12y ago
      Me too, its a great bit of advice that I had never even considered before! bookmarked!
  • starik36 12y ago
    So Scotty-based software development?
• vinkelhake 12y ago
  I've read that story before and always wondered what kind of profiling they were doing that apparently allowed those two megabytes to "fly under the radar". The CPU equivalent would be the "speed up loop" that somehow avoids being recognized by a profiler.
• louthy 12y ago
  From my experience in the games industry, this technique is fairly common. Not so much in the sense of 'hiding' megs away from other programmers, but having team buffer space (by 'team' I mean engine-team, AI team,...). For example as an engine programmer you'd want to pre-allocate space for various resources (models, textures, etc.); some stuff is dynamic, like the currently active game entities. So you'd have preallocated chunks of memory for N entities, where N is the maximum number of entities you could handle at that time (at every opportunity you'd want to avoid classic memory allocators because they're slow and a fragmented heap could kill your game on a limited memory device; so everything would be done with fixed block-size, fixed length, linked-lists). It was relatively easy to 'hide' buffer space for a rainy day because the list sizes would just be magic numbers that were decided as 'roughly what we'll need for later'. They could be per level magic numbers, or system wide magic numbers. Nobody gives a shit about the magic numbers at the start of the project on development devices with more memory than the final device, and mostly nobody even knows what the game's going to be early on (this was something I saw a lot in the games industry: teams just feeling in the dark for what it is they're supposed to be doing for months on end). Towards the end of a project when things are tight, and you have a better sense of how much of each type of thing you'll need, that's when you start giving up the buffer. Reading TFA reminded me of how much I do not miss working in the games industry. It was fun while it lasted (I did it for 10 years, I left 10 years ago), but after a while this style of programming drags you down. It's too much stress, for mostly not enough reward. The last game I worked on: https://www.youtube.com/watch?v=G9zMWu6PfSM https://www.youtube.com/watch?v=G9zMWu6PfSM
• Too 12y ago
  When writing safety critical software for limited embedded hardware we had a policy that new features were strictly not allowed to use up the final x kilobytes of the memory, these were reserved for critical safety patches. You don't want to hardware recall millions of units because memory is too low for a software update. This was handled by a build step though, not someone secretly hiding allocation in the actual code.
• shultays 12y ago
  I wonder if there are more 'buffers' in the program if further optimizations are needed