5 ms·

>if I could transfer the pace of production from Ludum Dare into my normal work, I would complete a game like House of Shadows in less than 2 months While the

• ha-ha-ha 13y ago
  Hah, very interesting. On the other hand companies generally put their very best developers on new products and features - i.e. writing those first 1000 lines. While the mediocre devs get to extend and maintain those products/features, by copy paste or what got you.
  • chii 13y ago
    that's because its more fun to work on that new 1000 lines, vs having to dredge thru old code to add the 1000 lines.
  • leokun 13y ago
    I have never heard of a place where "mediocre devs" get siloed off as a normal way of operating a business. If you have under-performing engineers you should change your hiring and think about mentoring or exits for those you have already.
    • fournm 13y ago
      It's more common in enterprise-y settings, since you don't have to pay them as much. Hire a few senior people to do the heavy lifting and stick all the maintenance programming stuff on the others.
      • leokun 13y ago
        Do they know they are considered mediocre? I think I might change my career if I ended up like that.
        • ha-ha-ha 13y ago
          Do you know quite a few people will consider you mediocre if you don't have millions of $ ? Will that make you change your career?
  • mapleoin 13y ago
    That's because those first 1000 lines of code contain the project architecture and style which will heavily influence the next 10000 lines.
• antimagic 13y ago
  Another big difference is that at Ludum Dare, the programmer is also the product manager - is that feature going to take too long to implement? Well, good news, you don't have to write a report to the product manager explaining why it's going to take too long to implement and suggest three alternatives. No, you just identify the problem, pick an alternative that achieves the overarching aim in a different manner, and implement it. This effect is particularly insidious, because often the long slow complicated thing that the product manager wants is just the sort of interesting challenge that developers enjoy. They don't point out to the product manager that there is a simpler solution, because that would take away the shiny toy. LD does not have this problem because the developer knows that she can't allow herself to go off on a 3 week exploration of compiler theory, because otherwise her product won't be ready in time.
  • adcoelho 13y ago
    From my experience those slow complicated things are often avoided by developers even if it would allow them to delve further in some obscure interesting programming. The programmer's performance is also measured by their ability to achieve the goals within the defined deadlines and accepting a task just because it's interesting even if it means a big delay is not very common. At least in my working environment which is very deadline driven(as I assume most are). But I am not dismissing your argument on the delay imposed by the extra layer between the project manager and the developer, specially if they have no programming experience.
• benjamincburns 13y ago
  Sorry in advance for this; I think I put my pedant pants on this morning by mistake. I agree that complexity doesn't scale linearly. That's a very insightful thing to note. However, the fact that LOC correlates with "probability of a change causing unintended consequences" in many codebases is coincidental rather than causal. The underlying cause of the unintended consequences is almost always poor structure and/or poor planning. Two words: cohesion and coupling. Highly cohesive systems which are loosely coupled are far easier to extend and modify without fear of weird and unintended "spooky action at a distance" interactions.
  • Aylw 13y ago
    While this is true, keeping a large project from getting ... err, decohesed and coupled, takes a lot of time as well. You will have less lines of code, but you'll definitely spend a lot more time than that first 1000 lines on a large project.
  • zeteo 13y ago
    Beyond Aylw's very good point that loose coupling demands its own share of effort, I'd also like to add that it only delays the inevitable. Even if you manage to organize your modules in a perfect, non-leaking tree and to only reference bug-free, well-documented external libraries, you still have two fundamental problems: 1. Each module necessarily has access to functionality provided by all its "ancestors". In the best case, this number still grows logarithmically with project size, and accordingly the difficulty of adding or modifying code in a "leaf" module. 2. New libraries and language features are generally seen as a neverending bonanza. But before you can effectively modify a module you need to understand how it currently works, which necessarily involves understanding the external tools used in it (quirks and all). As the variety of these external tools increases with code size (at quite possibly a super-linear rate), the complexity of working with any given module deepens accordingly. The Holy Grail of software development would of course be perfect layering: each layer completely masks its predecessor, and is no more complex. Someone who achieved it could indefinitely roll off as much useful code on day 500+ as they did on day 1. But I'm not aware of any practice or methodology that dares to even remotely promise such utopian benefits.