Allen Pike 2015-11-25T22:03:23-08:00 Allen Pike The worst app 2015-11-24T18:00:00-08:00 Allen Pike <p><em>Update: This story now has <a href="#update">a happier ending</a>.</em></p> <p>One of the various things I do at Steamclock is provide support for our apps. Our music apps don’t require much support, and much of the email we get is positive, so tending to support is generally pleasant.</p> <p>Or at least it was pleasant, until recently. On September 30 I received a very concerning support email.</p> <blockquote> <p>Subject: Report &amp; Contact</p> <p>My app keeps skipping when i close to my lock screen or go on a different app, and it also keeps taking forever to play the song when i click on it, and it wont play song after song i have to manually click on a new song after one ends. Can i get a reply to these issues please?</p> </blockquote> <p>This is a terrible kind of email to get - it points to serious low-level problems with the audio engine, perhaps a media playback API regression or other critical bug.</p> <p>I responded immediately with some questions. I asked for some further details like the OS version and device, and I asked whether they’re using Party Monster or WeddingDJ. My worry turned to confusion when I received the reply:</p> <blockquote> <p>I am using the app Play Tube Pro-playlist manager.</p> </blockquote> <p>You’re using… what? I tried to clarify but got no response. Wrong number, I guess.</p> <h2 id="please-help-me">Please help me</h2> <p>A month later, I received another foreboding support email.</p> <blockquote> <p>Subject: Report &amp; Contact</p> <p>Is not functioning very well Please help me</p> </blockquote> <p>How terrible! We never want a customer to feel like that after using one of our… wait a minute. Report &amp; Contact? I’ve seen that before.</p> <p>I apologized to the user for what they were experiencing, and asked for a link to the specific app they were having trouble with. Bizarrely, they link me to an app I’ve never seen before: <a href="">Music Player &amp; Playlist Playtube manager</a> by Vi Tran, a shovelware YouTube app with a 1.5 star rating.</p> <p>Well, that explains it! These weren’t emails for a Steamclock app at all. I promptly made a TextExpander shortcut to explain that it’s not our app, and to contact Apple. Case closed, not my problem.</p> <blockquote> <p>Subject: Report &amp; Contact</p> <p>Hi please I cannot play music</p> </blockquote> <p>Sorry about that, not our app my friend.</p> <blockquote> <p>Subject: Report &amp; Contact</p> <p>No va bien es una mierda</p> </blockquote> <p>I don’t speak Spanish but that doesn’t sound very good… still, it’s not our app.</p> <blockquote> <p>Subject: Report &amp; Contact</p> <p>That’s the worst app I have ever purchased, it’s not even working and why the hell do you think you can put adds while I paid for that horrible app.</p> </blockquote> <p>Turns out, this is my problem. One email a month turned into one a week, then one a day, then multiple every day. Soon I was spending more time dealing with support for Music Player &amp; Playlist Playtube manager than I was for our actual apps. Particularly frustrating was the fact that many of the emails described problems that could plausibly occur in our apps. It was time to dig deeper.</p> <p>The App Store page revealed little, other than that I wasn’t the only person unhappy with this app. If you think the App Store reviews on good apps are negative, you should see the reviews on bad apps.</p> <blockquote> <p>👎 ★☆☆☆☆ <br />by stephaniechabot12983456688</p> <p>THIS APPLICATION IS REALLI NOT GOOD!!! I CANT LISTEN TO MY MUSIC!! AND WE NEED TO PAY!! OHHH HELL NO!!!!</p> </blockquote> <p>Well said, Stephanie.</p> <p>The app’s website link on the App Store went to <a href="">an unrelated company</a>, and the copyright credit was for <a href="">another unrelated company</a>. I contacted them, and they were as confused as I was. With no way to contact the actual creator of the app, the only solution was to get Apple to pull it.</p> <h2 id="time-to-die">Time to die</h2> <p>Now, the App Store review process is a mixed bag. While it definitely has some problems, its fickle nature has an upside. When an app is in egregious violation of common sense and decency, Apple can simply pull it from the store. All you need to do is contact Apple about the app.</p> <p>Unfortunately, one does not simply contact Apple about an app. The official way to complain about an app is via the “Report a Problem” link from when you buy the app. Of course, I’m not going to <em>buy this scam app</em> just to complain about it, so I dug up <a href="">an alternate form</a> to report a problem. Maddeningly, one of the required fields on that form is an order number - the one you receive when you buy the app. Stalemate.</p> <p>For a few more days I stewed. As each app victim wrote in, I asked them to contact Apple and complain, using their precious order number. Pretty soon, people started to report back that they <em>had</em> contacted Apple:</p> <blockquote> <p>I <strong>did</strong> they said to contact you!<br /> If I was owing money to you guys God forbid I would get black listed because it the other way around nobody has the decency to help!! Not good enough.</p> </blockquote> <p>Ookay. It seemed I had no choice - I had to get to the root of this. I pulled out the Steamclock credit card and, for $3.49 CAD, I bought Music Player &amp; Playlist Playtube manager.</p> <h2 id="into-the-breach">Into the breach</h2> <p><img style='max-width: 100%' src="/images/2015/playtube-screenshot.jpg" style="width:250px" /> I must say, Music Player &amp; Playlist Playtube manager is a truly remarkable app. Its novel colour scheme of black, gold, grey, and coral breaks new ground. The various bugs that immediately present themselves prove that this developer understands how important it is to “always be shipping”. Perhaps most notably, in a market suffering a race to the bottom, this developer showed true entrepreneurial spirit by charging $3 <em>and</em> putting up a full-screen modal advertisement every few seconds.</p> <p>As interesting as the app was, my attention immediately fixated on the prominent menu item titled “Reporting”. Tapping this composed an email – addressed to me, titled “Report &amp; Contact”, and eager to capture your thoughts and feelings about the app.</p> <p>I took some notes and screenshots and contacted App Store support. I explained that the app was buggy, not working as advertised, and instead of providing a way to contact the developer, was redirecting their angry support email to me. I asked them to pull the app.</p> <p>Their initial response was, remarkably, that I should contact the developer. Now don’t get me wrong, as a developer I’m glad that’s in their script. Still, in this case, not so helpful. After some further explanation they refunded my purchase – the one I made so I could ask them to pull the app – but beyond that would only direct me to the generic <a href="">feedback form</a>. Rest assured, I filled that form with an incredibly convincing explanation of why the app was toxic waste and should be pulled. So far though, it hasn’t swayed anybody.</p> <h2 id="electric-boogaloo">Electric Boogaloo</h2> <p>Yesterday I got an unexpected email, congratulating me on launching some app called “Feeling Drawing”. I checked the store, and sure enough a new app had just gone live, featuring virtually the same icon as the Playtube app, but this time called Feeling Drawing and attributed to “Solaro Nohimdad”. This time, the app’s support website was listed as They even went as far to proclaim the app “© Steamclock”. In the immortal words of Stephanie, OHHH HELL NO.</p> <p>I immediately <a href="">reported trademark violations</a> on both apps to Apple Legal. The good news is that they pulled Feeling Drawing from the store within 24 hours. The bad news is that Music Player &amp; Playlist Playtube manager is still at large, laying waste to customers’ sat worldwide.</p> <p>I suspect that sooner or later, whether due to my tortured wails or the deluge of one-star reviews, Apple will pull this particular piece of garbage. Even when that happens though, many questions will remain. Does the App Store need a formal policy on app support? How many more junk apps are they going to put up and attribute to us? Am I on a shockingly convoluted and drawn-out episode of <a href="">Punk’d</a>?</p> <p>Anyway, time to get back to work. It looks like I have a bunch of support email to answer.</p> <hr /> <p><strong>Update:</strong> <a name="update"></a>Multiple helpful folks from Apple promptly reached out about this post, and I see that Music Player &amp; Playlist Playtube manager has now been removed from the App Store. This is a win for users and a win for my support inbox.</p> <p>In the longer term, I hope they put together a policy to deal with this kind of scam. This is surely not the only offending app. In fact, I was notified today that <a href="">another scam app just went up</a> that uses our website as their support link. Still, forming good policies takes time, so I wanted to thank the folks at Apple. They do care.</p> Being less wrong 2015-10-31T18:00:00-07:00 Allen Pike <p>Estimating software development is hard. There are a mind-boggling number of variables and tradeoffs involved - which is part of why we love software in the first place. Great software is built with experimentation, intuition, and iteration. This makes it both very satisfying to ship, and famously hard to predict.</p> <p>Estimation becomes even harder when you’re doing something new and ambitious. This is a problem, since Steamclock is in the business of doing things that haven’t been done. We don’t churn out a series of apps in a certain genre, build software from templates, or get within 50 meters of a Drupal installation. We like to build exceptional things, yet by definition exceptional things are poorly understood.</p> <p>Some engineering managers attempt to cope with this challenge by avoiding estimates. It will be done when it’s done, they muse, tautologically. It’s well known that estimates are usually wrong, and that iterative development is the way to build great software. Given that, refusing to give estimates can give engineers a zen-like high. If you never say how long it will take, you’re never wrong when it takes a long time.</p> <p><img style='max-width: 100%' src="/images/2015/over-budget.jpg" /></p> <p>Unfortunately, if nobody knows how much work it is, nobody knows whether it’s worth doing. Estimates, at least rough ones, are necessary for an organization to allocate resources well. Every team has a long list of things it would like get done - whether it’s adding Spotify support, shipping an interesting new app, or rewriting that god-awful vortex of Objective-C++ that an intern wrote in 2004 and somehow is still a major part of this business-critical Mac app oh god how is this code even working.</p> <p>As appealing as these projects may be, they first need a sanity check that they’re a good use of your time and money. This is obviously true with big ambitious projects, but is even the case for smaller additions or improvements. A small feature may seem like an easy win, but a rough estimate may uncover that it requires solving an <a href="">NP-hard problem</a> and thus may not be your top priority.</p> <h2 id="if-my-calculations-are-correct">If my calculations are correct</h2> <p>Estimation is especially important in the world of consulting. Your initial estimate is often one of the few things a prospective client knows about you, and a lack of a previous working relationship often means they’re going to take it very seriously if your estimate is wrong. Contractors in any field need to manage their communication around time and cost precisely.</p> <p>I learned this the hard way as a teenager. I did my first stint as a contract software developer at the end of high school, and it was, well, educational. Software engineering books enumerate many of the estimation and project management errors you can make, and early on I succeeded at <a href="">making all the errors in a single project</a>.</p> <p>Whether by crash course or gradual study, engineering managers learn a lot about managing time and costs. We develop an intuition for certain kinds of technical or product decisions that tend to be surprisingly risky or expensive. We learn to be mindful of the critical path, keeping an eye out for slow tasks that might block progress further down the line. On larger teams, we learn to estimate the accuracy of the folks contributing to our larger estimate, and how important it is to communicate the level of certainty we have in our estimates.</p> <p>Once a project starts, we also learn to watch for scope creep. We learn about <a href="">Parkinson’s Law</a>, and know that even the healthiest buffer on an estimate will be squandered if we aren’t vigilant. We also develop an intuition for progress, feedback, and quality, allowing us to continually re-evaluate our estimates to make sure we’re on track.</p> <p>After well over a decade of managing projects, I can now consistently ship quality software on time and budget, <em>and</em> avoid overtime or undue stress on my team. What once seemed unpredictable is now routine. This has made it easier to put the few projects that do have budget problems under the microscope.</p> <h2 id="your-proposal-has-been-selected">Your proposal has been selected</h2> <p>As we’ve gotten better at shipping projects as estimated, we’ve noticed that projects that end up having trouble are often projects where the client was evaluating us based on price. It doesn’t seem to matter whether we’re up against some offshoring firm or a lavishly budgeted consulting giant. For some reason, the price-conscious projects end up going over budget more frequently.</p> <p>Now, we’re not a sales-driven studio. Most of our work comes from referrals, and those projects tend to be seamless and great for all involved. For work we’re competing for, though, we sometimes end up doing proposals, and potential clients evaluate us on what we propose. Unfortunately, studies show that no matter how thoughtful proposals may be, their natural error distribution means that the average accepted proposal is an underestimation.</p> <p>In <a href="">The Influence of Selection Bias on Effort Overruns in Software Development Projects</a>, a team at the University of Oslo observed this exact phenomenon. Clients who consider cost estimates when planning a software project will on average choose proposals that are under-estimated:</p> <blockquote> <p>Only the estimates leading to actual projects will be evaluated with respect to accuracy and bias. This means that the previously reported strong tendency towards effort overruns in software projects potentially may have been caused by how project proposals are selected rather than, for example, by poor estimation processes or a disposition towards over-optimism among software professionals.</p> </blockquote> <p>In the study, they found the same thing we found via anecdotal observation: the more price sensitive a client is, the worse their project will go over budget. In the extreme case, a government organization is obligated to choose the lowest bidder for a project, and so will generally choose the vendors who have made the most extreme estimation errors. If you’ve ever observed government in action, this will not surprise you.</p> <h2 id="the-more-you-know">The more you know</h2> <p>Selection bias is just another entry in the bestiary of problems to avoid when you’re seeking to reliably ship software. Like its cousins, it’s a complex issue that’s impossible to avoid entirely, but being aware of it is half the battle.</p> <p>Great product teams avoid selection bias by prioritizing features by how valuable they will be be to customers, and being willing to experiment with or prototype projects even if preliminary estimates indicate they could be costly. Great consulting studios avoid selection bias by not competing on price, instead winning work based on their reputation for shipping great software rather than fixed bids and racing to the bottom.</p> <p>Either way, the process is the same: we continue the neverending battle to be less wrong, one project at a time.</p> Working Title 2015-09-30T18:00:00-07:00 Allen Pike <p>We recently interviewed a developer who was a new grad, brimming with enthusiasm. They answered our interview questions deftly, did well on our coding test, and presented a side project app that was sophisticated for somebody only six months out of university. Even better, their primary language was <a href="">Swift</a>.</p> <p>They had been writing Swift 70 hours a week, and were working methodically to develop their skills at an accelerated rate. Their goal, which they hoped to pursue by learning from our team at Steamclock, was to become a “senior developer” in 1.5 years.</p> <p>Now, I love enthusiasm and a can-do attitude. In fact, for junior developers, it’s one of the things I value most. That said, idea of a new grad toiling 70 hours a week trying to soon be deemed Senior Developer ruffled my feathers. To start, constant overtime <a href="">is unsustainable and counterproductive</a>. More than anything though, the mere thought of a new grad expecting to be a “senior developer” in less than two years got me agitated, even though I couldn’t articulate why. Even though I use the term “senior developer” when talking about growth or putting together a team, I realized that I didn’t have a working definition of what it means.</p> <p><img style='max-width: 100%' src="/images/2015/business-card.jpg" /></p> <h2 id="untitled">Untitled</h2> <p>We’ve never really had titles at Steamclock. I’m a co-founder, and Nigel is a co-founder. For the most part I run the business, but I’m not Chief Business Runner or chief anything else. Any attempt to coin a Chief Something Officer title for myself never really captured what I do, and felt overwrought for a ten-person team. I’m not a chief, I just run the place.</p> <p>Beyond the founders, we employ developers, designers, and somebody who helps us manage our office. Like most independent software shops, we prefer flexibility over formality. Job titles, especially when assigned to individual contributors like developers, are a formality - harbingers of politics and bureaucracy. Rands even goes as far as to <a href="">declare them toxic</a>:</p> <blockquote> <p>The main problem with systems of titles is that people are erratic, chaotic messes who learn at different paces and in different ways. They can be good at or terrible at completely different things, even while doing more or less the same job. A title has no business attempting to capture the seemingly infinite ways by which individuals evolve. They are imprecise frameworks used to measure the masses. To allow leadership to bucket individuals into convenient chunks so they can award compensation and measure seniority while also serving as labels that are somehow expected to give us an idea about expected ability. This is an impossibly tall order and at the root of title toxicity.</p> </blockquote> <p>Rands is right, as he often is. Attempting to quantify a developer’s skill or value or experience is at best imprecise, and at worst gross. In a perfect world, we could just put that aside, pay every employee the same, and avoid the process of labelling some people senior and other interns. These aren’t <a href="">spherical developers in a vaccuum</a>, they’re people. Unfortunately, without titles you can end up with a different kind of vacuum.</p> <h2 id="the-art-of-the-title">The Art of the Title</h2> <p>Titles help people outside your organization orient themselves to who they’re talking to. Avoiding titles or, alternatively, letting people choose meaningless titles makes it harder for new hires or clients to grok your organization. We’ve worked with large companies that lack formal titles, and determining whether the Chief Pixel Assassin or Senior Code Snorfler has the final say on a key product decision can be a… challenge.</p> <p>A lack of formal designations in a larger organization can also make it harder for certain people to communicate authority. For example, people from underrepresented groups in senior roles can have an even harder time communicating their authority if they don’t have a title to back it up. You can dislike titles all you want, but if the strongest developer at your company is a black woman, equipping her with business cards that actually say “Principal Software Developer” is going to be a net win. Of course, that’s only helpful if your institutional biases don’t prevent her from attaining that title in the first place.</p> <p>Besides their value in communication, titles’ most important role is to help reason about growth. Talented people want to grow their skills and responsibilities, and need recognition and compensation for that growth. Doing that in a totally ad-hoc way without any kind of labels gets hard as a company grows.</p> <p>Even at our size, where we’re small enough to do without titles, we need some way to discuss professional development and paying people fairly. We need to make sure bright developers with a lot of potential see a path to becoming seasoned developers with a lot of skill. We also need to talk about compensation, and understand what it means when some competitor is paying “senior developers” a “shitload of money” to “move to San Francisco and live in a closet in the Tenderloin”.</p> <h2 id="the-title-sequence">The title sequence</h2> <p>With that in mind, I attempted to hash out for our Enthusiastic Applicant what we mean at Steamclock when we discuss terms like intern, junior, and senior, even if we don’t have those terms on any business cards.</p> <p><strong>Intern</strong>: Does not actively sabotage app development. Is learning the language and tools, probably has some education but hasn’t held a full-time development job. Isn’t experienced enough yet to evaluate further.</p> <p><strong>Junior</strong>: Has shipped at least one app, and are generally productive. Junior developers still typically need oversight, might not be comfortable yet with gnarly tasks like choosing open soure components or code signing, and are still primarily evaluated on enthusiasm, attitude, and growth. <em>Typical experience: 0-3+ years.</em></p> <p><strong>Intermediate</strong>: Has the experience and wisdom to lead technical direction on a small project, coach and review other developers’ code, and prioritizes well. Has become comfortable with the technical tradeoffs that present themselves day by day, and actively works to better understand these tradeoffs and design patterns. Intermediates can work directly with non-developers and know when to escalate issues, technical or project-wise. Intermediates have developed the skills for discussing project issues productively with the team, and have refined key communication skills around software development. Technology wise, they have knowledge of the various tools and frameworks that relate to their work, and have gotten relatively fast at picking up new ones. When they encounter technical problems, they are usually hard problems like caching or naming things. <em>Typical experience: 2-6+ years.</em></p> <p><strong>Senior</strong>: Has the wisdom, intuition, and humility of a battle-worn developer. Can accurately estimate tasks and projects, primarily by drawing on experience. Has led other developers and is good at motivating, teaching, prioritizing, and coordinating. Has overcome and can spot common bad instincts like “not invented here” and “second system”. Has internalized the costs and general futility of overwork. Builds good relationships with other employees and clients using a honed sense of organizational and personal awareness. Thinks in terms of product and business success. Could probably have their own company, but knows they’re stronger as part of a team. Can systematically address technical problems that are mysterious and messy. Has developed specialties and technical expertise in specific areas that makes them unusually valuable on certain projects. Is active in the community and helps recruit and interview new talent. Is in control of their own motivational whims to the degree that their productivity isn’t limited to tasks they enjoy. <em>Typical experience: 5-15+ years.</em></p> <h2 id="title-card">Title Card</h2> <p>Having read my outlines of what career development might look like at Steamclock, our Enthusiastic Applicant was humbled yet motivated. They realized that becoming a senior member of a software team wasn’t just about having typed a lot of Swift and having read a lot of blog posts, but more about being tempered in the fire of mistakes and self-improvement. They still like the idea of getting to a “senior” level in a couple years, and while that seems exceedingly unlikely, why not let them try? Worst case scenario, we have a bright developer working on getting better at their craft for years to come.</p> <p>Well, worst case scenario is that they leave after six months to make a hojillion dollars burning themselves to a husk at Amazon. But it’s my job to be an optimist.</p> <p>Wait - Chief Optimism Officer? Nah, co-founder will have to do for now.</p>