Hacker News Reader

Comment by tolmasky | Hacker News Reader

The nice thing about Twitter apps is you can actually say "I'm pretty sure if just one person who cared got put on it, it could be WAY better than what we have today", because unlike other apps that we all "couch architect", we actually have the proof of this being the case. We have numerous case studies of 1 person or very small teams making really great Twitter apps (apps that actually influenced iOS design!).

Twitter has a ton of employees. Unless you actively believe the Mac app will hurt your business there should just be one full time engineer on it, someone who loves ObjC and UI design, who can use Twitter as a testbed for crazy UX ideas. If its not important, than whats the worst that can happen, you generate a ton of developer respect?

View on HN

> … there should just be one full time engineer on it …

Agree with everything you just said, except, please make it two engineers. Speaking as a prototypical eng manager who typically inherits these types of projects when "that one engineer" leaves the company, I strongly believe that any job worth doing is worth doing by more than one person. (Plus, a good peer, just to bounce ideas off of and do informed code reviews with, is worth their weight in stars.)

PS: I thought @jack was going to open the third-party ecosystem back up again. That also has the potential to help address this problem. Did that not happen?

[1] http://www.theverge.com/2015/10/21/9586084/jack-dorsey-twitt...

> PS: I thought @jack was going to open the third-party ecosystem back up again. That also has the potential to help address this problem. Did that not happen?

I asked Jack about the third-party ecosystem on his producthunt Q&A, he said Fabric is a strong offering and they're building more to repair relationship.[1] I don't know if them building developer tools is same as repairing relationships though.

[1] https://www.producthunt.com/live/jack-dorsey#comment-202231

Hmm, I don't know about anyone else, but personally I can't stand Fabric! It gets in my way far more than it helps, with the weird utility app they force you to keep installed, and a single dashboard which does lots of things, but none of them really well.

There are always two: a master, and an apprentice. :)

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.

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.

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.

Bureaucracy increases, productivity falls, your best people leave and you end up in a worse place than when you started.

"Your best people leave" is a much worse problem in the case where you have just one person who then leaves.

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.

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.

Reply on news.ycombinator.com