5 ms·

It's a bit naïve to think all it takes is one engineer. First of all, you probably need at least more than one to keep you honest. Then a designer. Then probabl

It's a bit naïve to think all it takes is one engineer. First of all, you probably need at least more than one to keep you honest. Then a designer. Then probably at least a PM. When comes the time to ship, you need to involve release engineers and QA and... Really not worth your time when the app in question is targetting a minuscule market (Mac OS) that's not part of your core business. Better outsource, validate when they're done and ship it.

aaronbrethorst 11y ago
I generally try my best to avoid being snarky, but you picked a bad example here, given that the first (couple?) version(s) of the official Twitter for Mac...and iPhone...and iPad apps were all called Tweetie, and written by exactly one person: Loren Brichter. So, no, it's not naïve. In fact, it would be entirely expected, given that that's how this app started out.
- ptaipale 11y ago
  Yes, the first couple of versions can be done like that. But when you're going to maintain and develop further for a long time, the game changes. You need sustainability. The one developer may want to have a longer holiday. She may be run over by a bus or get cancer or have a child, so you want to have another person who knows how to develop. When the app becomes more complex and there are multiple platform versions to support, it will require more QA than one developer can do. You will want to have more than one person to work on it, and you need structures for that.
  - tonyedgecombe 11y ago
    Bureaucracy increases, productivity falls, your best people leave and you end up in a worse place than when you started.
    - ptaipale 11y ago
      "Your best people leave" is a much worse problem in the case where you have just one person who then leaves.
      - tonyedgecombe 11y ago
        It depends on whats left behind, if you spend all your time on trying to make your organisation safe from every calamity that might befall it then you probably aren't going to be that competitive.
        ptaipale 11y ago
        Well, you don't have to try to make your organisation safe from "every calamity", but it would be prudent to look at reasonable risks - like that your only developer becomes permanently ill, or wants to do something else at some point in his or her life. It is possible that in some business your competitiveness cannot cover the cost of mitigating this kind of risks, but then it's not a very good business.

aaronbrethorst 11y ago

I generally try my best to avoid being snarky, but you picked a bad example here, given that the first (couple?) version(s) of the official Twitter for Mac...and iPhone...and iPad apps were all called Tweetie, and written by exactly one person: Loren Brichter. So, no, it's not naïve. In fact, it would be entirely expected, given that that's how this app started out.

ptaipale 11y ago
Yes, the first couple of versions can be done like that. But when you're going to maintain and develop further for a long time, the game changes. You need sustainability. The one developer may want to have a longer holiday. She may be run over by a bus or get cancer or have a child, so you want to have another person who knows how to develop. When the app becomes more complex and there are multiple platform versions to support, it will require more QA than one developer can do. You will want to have more than one person to work on it, and you need structures for that.
- tonyedgecombe 11y ago
  Bureaucracy increases, productivity falls, your best people leave and you end up in a worse place than when you started.
  - ptaipale 11y ago
    "Your best people leave" is a much worse problem in the case where you have just one person who then leaves.
    - tonyedgecombe 11y ago
      It depends on whats left behind, if you spend all your time on trying to make your organisation safe from every calamity that might befall it then you probably aren't going to be that competitive.
      - ptaipale 11y ago
        Well, you don't have to try to make your organisation safe from "every calamity", but it would be prudent to look at reasonable risks - like that your only developer becomes permanently ill, or wants to do something else at some point in his or her life. It is possible that in some business your competitiveness cannot cover the cost of mitigating this kind of risks, but then it's not a very good business.