5 ms·

> As for me personally, without deadlines I tend to procrastinate. I agree. Deadlines are highly motivating and help me determine scope of work I need to do.

• kristianc 8y ago
  > "Make a tool that does X. We need it by Friday so we can use it for Y." > Me: "Ok! I can probably whip up something quick and dirty in python that gets the job done!" And this, when abstracted across an entire team or company, is what gets us unreadable code and hopelessly buggy software. Productive does not always equal effective.
  • cgrealy 8y ago
    This is a problem of incomplete specifications. "Make me a tool that extracts, collates and graphs data from this spreadsheet. We just need it to run once this friday" "Done, super fast, slightly buggy python script it is!" vs "Every month we need a tool to pull data from multiple sources, and push it to a reporting framework. It needs to be scalable and robust... oh and we need it by friday" "Well, you're not getting it by Friday." Deadlines should be a conversation, not a demand.
    • Baeocystin 8y ago
      Fast<->Cheap<->Good/Pick 2 is up there with the second law of thermodynamics in its inviolability.
  • vkou 8y ago
    The converse, when abstracted across an entire team or company gives us architecture astronauts that don't ever actually ship anything that works.
    • andbberger 8y ago
      Great so we've established you want to be somewhere in the middle.
  • freehunter 8y ago
    Meanwhile "I'll learn a new language to do this" when abstracted across an entire team or company leads to code that no one knows how to maintain when the one person who wrote it leaves.
    • opportune 8y ago
      I feel the same way about "clever" code. Most of the time "clever" code isn't really any more efficient than a naive approach, it's just a way for a developer to code golf at work by abusing / using uncommon syntax or idioms. Which is really a net negative since other people need to be able to read your code
      • MisterOctober 8y ago
        Yep! "Clever" code always reminds me of Kernighan : "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it."
      • duncanriach 8y ago
        It seems to me that the smarter someone attempts to appear the less smart they truly are. True intelligence appears as clarity.
  • mikeash 8y ago
    It's also what gets us great code and reliable software, when done properly. Engineering is all about tradeoffs. A major tradeoff is time versus... just about anything else. Deadlines help you know how to make that tradeoff properly.
• bigiain 8y ago
  One of the best old-school pieces of advice I ever got was "always throw away the first one". (Widely advised on comp.lang.perk.misc back in the 90s... Tom Christiansen is the name I've got mostly attached to it in my head.) I'd read that as two requests. 1) "Make a tool that does X." 2) "Fast track a tool that does X by Friday so we can do Y." The use the time prototyping X quickly to learn the entire space around solving the problem X, while mostly aiming to just solve the parts of the problem that will roadblock Y, with the agreement that this is only a prototype and while the Y team may choose to put it into production, there'll also be a much more complete set of requirements and specification of "The X tool", (which may well include Rust evangelism, proper testing infrastructure, performance benchmarking and scaling plans). (Note: _most_ of the time this does not actually get acted upon, and I've got several hilarious war stories about "quick hacks to get us past next week's deadline" that out survived the company that I implemented it for. But a least I had it in writing...)
  • teddyh 8y ago
    > always throw away the first one That’s a quote from Fred Brooks’ The Mythical Man-Month (1975): ”[…] plan to throw one away; you will, anyhow.”
• therealx 8y ago
  A deadline gives you the freedom to ship something imperfect.