Sunday, April 12, 2015

One game a month

Last month I decided I would take a break from srs bzns work and run a little experiment. Game development is why I got into software development in ~5th grade and I want to explore that again.

Turns out, games these days are a LOT easier to make. The real game engines are so good that they make GameMaker look like a joke. I bought this pragprog ebook for $20 and the first thing I thought was "Wow this book is short. Is this a full book?"

By the end I was pretty sure I could reasonably make any 2-dimensional game I could imagine. March was a short month because I used a lot of the time to learn SpriteKit, but I did what I set out to do: make a game and release to the App Store.

So here it is.

Ball Hit Targets

iPad only, head's up multiplayer target shooting game. I was drawing inspiration from a popular commercial from the 90s.

As you can probably guess, I ran out of time for branding and theming the app. 

So why am I doing all this?

1.) Games are fun

No one will call you a shit-eating bastard if there's a minor bug in a game (I assume). Remove a feature or break something slight in a productivity app and someone is about to get very, very mad. There was that flappy bird fiasco, but if I ever earn game $$$ like that you can call me whatever you want.


With a one month budget, there is 0 time for fucking around, at least in the productivity sense. So many business apps lose time to time-sinks that have 0 business or technical value and act as masturbatory exercises for developers. Wanna build a new web app? You MUST use the newest terrible javascript framework, css framework, and build tools. Fuck if any of it works together, but after you spend 40-80 hours setting things up, it works okay...I guess.

"MVP" has become a buzzword that everyone likes to claim they're doing. Usually it means either a product that got exploded well beyond scope of what it should have been, or it's a single page email collection tool. 

The former burns a lot of money and the latter is about as useful as asking your mom if she would pay you for the app. My mom is great and she would buy all my apps, but it doesn't tell me what I'm building makes sense or has a market. 

And if you think you have all the time in the world to build your product, I promise you that you do not. Another faster company is better than you and WILL beat you to market. They will iterate you to death; their 14 iterations will DEMOLISH your 1 grand design. Then you can fire your grand designer and try a new grand design, you big dummy.

3.) Fame and Fortune

Ha, I wish. But it does say something that the highest grossing apps in the app store are always, always games. And the competitors in other categories are usually big companies and not indie developers. Indie developers are lucky if they can live off of app sales. 

Game developers are too, but there's always the potential of making a game that really sticks with people that could earn well more than you could ever make with a business application. Games are the media Of The Future and relying on skills that exist in the static readonly world is probably a loser's game.

All but a few of my favorite games in the past few years have been indie titles, and it usually comes down to a single factor - a core gameplay mechanic that is so good that it props up an entire game on its own. And the stories in modern games resemble bad sixth grade novellas more than proper fiction; 343 Studios put out a game where "Save the eggheads" was canon and part of the plot. I used to wonder why I skipped all text in games, and then I realized I didn't. I skip text in games with bad text. I can't read bad translations or overly dramatic nonsense. And yet Sorcery! is probably my favorite game right now, and it's all text. The difference? Good writing.

4.) To lose money

I don't necessarily want to do this, but it's necessary. Without a business model or marketing strategy for any game I release in a month (if any game made in a month will be worth anything), I will lose money. Getting sound/art/writing/anything at scale and on time costs money. 

Unlike software developers, artists and sound designers are scrooge-like and do not release anything for free. If you label your work free and require attribution and only allow non-commercial works, FUCK YOU. You can license however your heart desires, but do not call that free.

This whole endeavor will likely cost me a good bit of cash, so I'll consider what to do next when my year is up. I'm hoping the investment in learning and releasing will pay off, but we'll see.

Wednesday, May 7, 2014

Engineer Driven Development

What do startups, big enterprise teams, and individual developers have in common? If left unchecked, they all tend to drift toward engineer driven development.

If you try to follow lean, or any other buzzword that focuses on building product, EDD will wreck your product and leave you with an unprofitable, unmaintable pile of garbage.

Every company inevitably runs into the need to solve a solved problem. You need monitoring? New relic. You need a web service or need to build a web app? You can probably name 15 frameworks that would do the job pretty well. You need elastic server capacity? There's EC2.

But plugging known, tested, common components together isn't fun. It's work. No one gets excited talking about how they set up rails with postgres and now they have working REST endpoints.

You know what's exciting? Writing your own web framework. It's riddled with edge cases and holes, and you can spend literally infinite time in a sandbox accounting for different use cases you don't have now but might have one day*.

* You'll never have those use cases.

But Stefan! Basecamp did it! Basecamp built Rails!

Yeah, they did. And you're not DHH. We all want to be attractive, racecar-driving open-sourcistas with danish accents, but that's not reality. We build software in the real world, and in reality, your garbage in-house web framework won't scale beyond 10 customers, requires millions of dollars a year in engineering time to maintain, and is four to ten times as inefficient to develop in than the free or marginal-cost competitor you sought to displace.

And let's not forget onboarding. If you ever plan to work with a single other person, they need to learn your bullshit in-house solutions to solved problems. Instead of instant familiarity with your new relic account or rails, they need to parse through your engineering masterpiece to figure out how to change a line of text on a webpage.

This is just the literal cost of building solutions to solved problems instead of using open-source tools or buying the right tools for the job. Opportunity cost is much higher.

What did you lose by spending a year building a replacement to a known solution?

You lost a year of product development. 

If you're small, this can be financially disastrous. If you're big, you can only eat your own crap so many times before you're so slow and bloated that you can't compete.

The engineers had really good reasons for building their own dog-crap. Or at least you think they had good reasons. At the very least they were persuasive. Who could have known that we would have lost so much time building the product?

So who's responsible? The engineers? Sure, but blaming them won't get back all that money you lost to competitors.

Everyone is responsible for stopping EDD: technical founders, managers, testers, developers.


Tuesday, November 12, 2013

App Store approval after 4 rejections

A few weeks ago, a small app I created to help with Pokemon battles was rejected from the app store. Four rejections later, I'm in the app store. Here's the story.

If you play Pokémon online, you quickly realize that most everyone online is serious business. A misplay will cost you the game. So I created the app.

Submission 1: Pokemon Types

Rejection: 10.6 

10.6: Apple and our customers place a high value on simple, refined, creative, well thought through interfaces. They take more work but are worth it. Apple sets a high bar. If your user interface is complex or less than very good it may be rejected
When I submitted the app, there was no other website, app, or experience that provided that interface. So I pushed back. Then I got this:

22.2: Apps that contain false, fraudulent or misleading representations will be rejected

Fine. Despite the myriad of "Pokémon" named apps on the store, I figured it was reasonable to change the name and re-submit the app. 

Submission 2: Quick Attack

Rejection: 10.6

Okay. Maybe someone at app review just didn't like the app. As I continued battling, I realized it would also be useful to see a base stat breakdown of each pokémon. Should I send out my special sweeper or my physical sweeper? If we're both geared and specced for speed, who will move first if I attack now?

So I expanded the app, hoping to get past the dreaded, subjective 10.6 rejection. At the same time, another app was approved to the app store with a nearly identical interface, flaunting the word "Pokémon" all over the app and in the app name. Fuck me.

Submission 3: Quick Attack

Rejection: 10.6

Wat. Since installing the app on my phone, it has been my most used app, aside from my podcast client, maybe. I know there's value, so I appeal.

Rejection: 22.2

This time, I get some more information. They tell me that the app icon is at issue, despite never mentioning it before and just pasting the fucking manual at me. RTFM has never felt more depressing. But an app icon is fixable. I remove any reference to anything and try one more time.

Submission 4: Quick Attack

Is the icon awful? Sure. I intentionally made the icon as bland and lifeless as possible to avoid any potential conflict with any trademark of any product in the world. I may accidentally bear resemblance to some nation's flag. I wouldn't know. I just wanted a quick submission.

Rejection: 10.6 and 22.2

Ooh! A double whammy! Except this time, I know for damned sure I've addressed all the issues that app review had with the app. In one last attempt, I appeal again. This afternoon, I get this:

Huzzah. Ready for Sale! It took several weeks, but I finally did it. I fought the law, and I won. 

Do I feel good? Not really. A simple app was delayed several weeks without a whole lot of feedback in the rejections. Why is app review time 7-10 days? I hear Apple is full with profit, literally brimming with cash and little to do with it. Apps are the cornerstone of why iOS is so successful. You think Apple would give a fuck.

With a tight feedback loop, I could have handled these 4 rejections in under a week. Does it really take 8 days to review an app with two views? For a new app or product, iteration is everything, and Apple makes it really, really difficult. I wish it didn't.

If you like Pokémon, go download Quick Attack from the app store. I hear your chance of finding a shiny improves if you leave a tip.

Saturday, November 9, 2013

10 questions to ask your potential employer

The interview is all too often driven by the employer. Can you handle this workload? What are your strengths and weaknesses? How do you feel about this aspect of the business?

But at the end of the interview, you do not know enough to know if you will actually love and enjoy the work. How many developers or designers do you know who have worked at a place for less than a year? Less than 9 months? I bet more than a few.

Here's some questions you should ask before committing a significant portion of your life to a company.

1.) What's the process like? How do you build software? Do you describe yourself as "lean", "agile", or "scrum"?

This can make or break a position. If the work culture hasn't been somewhat formalized, you might be entering a position where your main job is managing the chaos. If a company thinks they're doing "lean" or "agile", this might mean you're walking into a formalized reasonable process, or it could mean that you spend half your time in meetings with decks of cards arbitrarily assigning cost to problems. The most important thing is that someone, at some time, has consciously decided how work is developed at the company, and it makes sense. Be cautious of too many buzz words.

2.) How do designers work with developers?

Do they even have designers at all? Is design a top-down throw-mockups-over-the-wall situation, or is there any room for collaboration and iteration? Developers acting as their own agents of design almost certainly means that design isn't important to the company, and most of the products probably suck. If you have a really good product person with design sense, you might get lucky here, but more often than not everyone is shooting from the hip and it will show in the products you build.

3.) What's the state of automated testing? Continuous integration?

Automated testing can be awesome. I use automated unit/integration/functional (where viable) tests for any products I build, and it shapes the interfaces and makes code maintainable long term. But you can hit extremists on either end of the spectrum.
  1. We don't have tests.

    Get out. Your about to slam into a million line code base where only the original authors have a chance of making changes and not breaking the product. And you'll be blamed for the breakage.
  2. We have 100% test coverage.

    Bullshit. Or most of your tests are asserting private method calls with mocks, stubs, and other 0-value tools that were invented to achieve 100% test coverage. Trying to change anything in the application will either break the entire test suite or break none of the test suite. Either way is dangerous. And you'll be blamed for the breakage.

4.) What *exactly* will I be working on? What's the tech stack?

Job postings are notorious for lying or on job postings to attract developers. Many times, there's one developer in the company who loves pet-technology-X, so he lists it on the job application, but it doesn't relate to the job at all. For example:

"Needs experience in rails, iOS development, HTML5, node..., and Perl experience is preferred."

What this really means:

"Most of what you do will be maintaining a 2 million line perl server application. I want to rewrite everything in rails and I like iOS, but we'll never actually do this."

5.) How big are the teams? How big will my team be? 

You can't move Mount Fuji, no matter how clever you are. If team sizes are small, and there aren't many teams, there's a very good chance you can make rational arguments and fix problems with the development process or with the team. In a large organization, you're going to crash against individuals in positions of power and change structures optimized to preventing change. Change is scary, and we've been kind of successful with the current process and 100/200/1000 people! Why would we need to change anything? You're the outlier, and you're the problem. In a smaller team, you can't be an outlier. That's math.

6.) Is there any allowance for remote work?

You may not even want to work remotely, or work remotely a significant percentage of the time. Still ask this question.

Why? This is a direct indicator of whether or not the company is looking for work output or warm bodies in chairs. Do you really want to work somewhere where the employee spending 10 hours a day in the office (mostly on reddit and in useless meetings) is valued above the employee producing 2-10x their output? Fuck no. Certain industries have strange legal reasons for requiring everyone work on-site, so that's one possible excuse for disallowing remote work, but by and large, "everyone needs to be in the office" === "we care more about warm bodies than results."

7.) Are there core business hours?

If all aspects of the business are perfect, but there's no room for you to pick up your kids, or work out, or attend your weekly book club, is the job going to work for you? Probably not. If you're dealing with customers, it's not unreasonable to need to cover a window of time, but it's still possible to be flexible with "core hours". A strict adherence to core hours might mean that most business processes are synchronous versus asynchronous, which will strictly bottleneck your ability to get shit done. Pry a bit here, and figure out exactly why there are core hours, and what it means about the company.

8.) Why are you hiring? Is this a new product? Scaling? Did someone recently quit?

A company in the midst of churn is a telling indicator that something is wrong with the company. It could mean that compensation is poor, or work life balance is off, or the work culture is toxic, etc. If someone left, find out why. If the company is scaling, you may be joining a 100 person company you believed to be a 20 person company.

9.) What's the coolest thing you've built here, personally?

I like to build products that ship. Some companies don't. Find out what the last successful project your interviewer worked on was, and when it made it into customer hands. This tells you whether the company delivers in small increments, or allocates huge budgets to failed projects. How many projects have you worked on that never made it into customer hands, or failed as soon as it was launched? How did you feel when that project ended? 

Asking what the "coolest" thing the interviewer has built will tell you if the employees take pride in the work they're doing. A software developer or designer will gush on a dime if they've built something even mildly interesting that even a single customer loved. This is what you want. 

Beware of "I built an internal tool that..." or "I built a flux capaciting tool that..." or "I rewrote an open source tool because...". Some developers like to jerk off to rebuilding the wheel and wasting business money on projects that strictly aren't required or useful to the business as a whole. Like I said, I like to build products. If you feel like you needed to rewrite the compiler, you're probably awful, and almost certainly wrong.

10.) What do you wish you had known about the company before working here? What's the worst part of this job?

All companies have problems. Stop tricking yourself into believing Canaan exists; it doesn't.

At a good company, your interviewer won't be afraid to be honest and divulge the shit. When someone isn't afraid to call out the shit, the shit can be fixed and changed. No relationship, company, or product is perfect. How you manage issues defines whether coming to work will be a slog or will invigorate you. "I have to deal with X today. Fuck my life." or "I get to try and fix X today. Today is the day we fix this problem forever."

At a bad company, you're gonna get a sales pitch. "My biggest weakness is being too devoted to perfection." Here are the possibilities:
  1. Your interviewer is lying to lure you to the job. They know that it's very, very costly and disruptive to switch jobs, so they figure you'll be stuck as soon as you join the company.
  2. Your interviewer is afraid to be honest. You've found a culture of silence, and you'd better be ready to put your head down and ignore problems. 
  3. Your interviewer has drunk the Kool-Aid. This is just as bad as lying, except they don't know that they're lying. If no one in the company sees the 80 hour a week forced overtime as a bad thing, GET OUT. You'll either get sucked into the brainwashing yourself or be forced to deal with people who cannot see that there are problems to be fixed. 

Not all companies are evil, but know what you're getting into. We only have so many years on this planet, and you don't want to waste those digging ditches with your head down.

Saturday, October 26, 2013

App Review rejection 10.6: Fuck you.

  • App rejection. Sometimes it's legitimate, and then sometimes it's this:

  • 10.6: Apple and our customers place a high value on simple, refined, creative, well thought through interfaces. They take more work but are worth it. Apple sets a high bar. If your user interface is complex or less than very good it may be rejected
Last week, I wrote a quick app to look up the type effectiveness against Pokémon as I battled my way through Pokemon Y. It's a fun game, but there's no resource out there that quickly and cleanly answers this question:

"When I'm battling a particular pokemon, what is its type(s), and from those types what are its weaknesses and resistances?"

There are 719 Pokemon, so the odds that you can remember the types of each pokemon are roughly 0.

Here's what I made:

Is the app simple? Yes. But that's the point. Any more or less information, and the app is useless. There's a $26 Pokédex app on the app store, and it's a steaming pile of trash. You know what I don't need when doing battle challenges or playing online? Videos of pokemon making sounds.

Nintendo is really bad at making interfaces, and it shows in their app.

No website or app exists that provides this kind of ease of use lookup, but apparently that doesn't matter. And this is the same app store that approves fart apps.

Friday, August 23, 2013

I love email

It sounds strange, right? For many people, email is a giant bucket of stress that most-likely will never get processed. "I have 500 emails in my inbox. What am I going to do?"

Exactly. What ARE you going to do? You've created a system whereby you can never process your inbox, and thus it's useless to you. How can you parse the wheat from the chaff when you have fields of wheat and a only a hand tool?

Here's why I love email:

Whenever I get a odd number of minutes to process my inbox, usually in the morning, or after lunch or dinner, I defer, delete, respond, or unsubscribe to every email. I do my own customer support, so my batch can sometimes get quite large. I find that processing these emails in the morning works best as my mind spins up.

If you're keen, you'll note that I'm using GTD, and I do it with Mailbox.

For me, email is a queue that *will* be processed. I ruthlessly unsubscribe and prune anything that isn't value-relevant to me or that I can't take action on. You don't need to read every email in your company to function. Newsflash, you already don't. Your 2-week late reply to a decision that needed to be made a week ago is worthless. Stop pretending you're on top of your incompetence.

I hear constantly that people get better response from calling than from emailing, and I have to imagine that this is at least a little due to the fact that email, for most people, is a giant bucket of spam and irrelevance that's never really going to get processed.

Because my mailbox is the source of my GTD workflow for general tasks, I email myself for each task I encounter throughout the day.

Here's what I did today:

  • Print shipping label for key
  • List iPad on eBay
And I processed those items with the rest of my email, in time I allotted for batch processing email.

You're balking at this point, and screaming and writhing because "you just have more important email." You don't. You have email you're not prioritizing or giving proper attention, and that doesn't help anybody.

Download Mailbox, and give it a try. Email GTD will change your life.

Sunday, July 21, 2013

Ruthless prioritization

When I think about how I manage work, I always draw parallels to how people manage their lives. When's the last time you were in this situation?

Chris: So, ready for lunch?
Bob: Sure, one sec. I just need to reply to this email. Should be 5 minutes.
Frank: Hey Bob, can you send me that spreadsheet when you get a chance? 
Bob: Right away.

Chris: Done with that email?
Bob: Had to stop for a sec. Give me another 5.
Angela: Bob, could you show me where I need to be looking to fix this accounting issue?
Bob: Sure thing.

All this time, Chris has been putting off starting a larger piece of work because of Bob's initial time estimate of 5 minutes. You might think that Bob is just a really busy person with a really important job, but I disagree. Bob is a mess who has no idea how to prioritize his work. He can't even get himself to lunch, let alone send an email or complete a serious task.

The problem with all of this is that Bob thinks he's being productive, when in reality he is fighting fires with no order or priority. I'm a big fan of GTD, and whether I'm working or going to lunch, I make damned sure that 
  1. I'm working on the most important project for my current context, and...
  2. That project takes priority and keeps getting worked before any lesser priority task.
A project, in GTD, is anything with at least two steps. I defer, delegate, or delete any project that comes along so that I can continue working on the highest priority thing. 

Food, sleep, and exercise are important. When you say "I don't have time", I hear "I'm awful at planning and waste a lot of time on Reddit".

The concept of "working through lunch" is asinine. You're not working; you're pretending you're being productive by reading email or attempting to accomplish other menial tasks while spilling food and liquids all over your $3,000 tool. You work, or you lunch. 

The next time you're in an airport, take a look at any laptop propped open at a restaurant table. Every single one of these people is exactly the same: miserable and distracted. Focus on what you're doing, and do it well.

I'm going to lunch.