The CODEGIRL documentary is streaming free on YouTube through November 5, 2015.
Category Archives: software
the state of the independent developer
I’ve been shipping software in various roles since I was an undergraduate student in 1997. I’ve done tech support, technical writing, software development, and user experience in the intervening years. I’ve shipped code in at least 8 languages, including Smalltalk and VAX assembler. I’ve contributed to and helped organize several tech conferences, ranging from programming languages to women in tech.
Although I had been a Mac user for some time, I officially became a part of the Mac developer community in 2005 when I joined Microsoft to work on Office:Mac. I was excited to join that team. Not only did I finally get to work on Mac applications (and with people who had been doing Apple development for 20+ years!), I was part of a vibrant community. I attended MWSF first as an engineer, and later as a speaker. I met many people who have long since crossed the line from fellow developer to friend.
I was a part of the community for the transition from PowerPC to Intel and the corresponding transition from CodeWarrior to Xcode. I was part of the community when the iPhone was announced. I was a part of the community when iOS really took off, and when being able to attend WWDC was not just a matter of getting employer approval but also the luck of a draw to get one of the relatively scant handful of available tickets.
When I started working on Office:Mac, I observed that there weren’t a lot of large Mac development shops outside of Apple. There was the Office:Mac team of ~250 at the time, and Adobe too, although I didn’t have a good estimate of how many Mac developers they had. Then there were smaller teams, like Quicken for Mac, VMware Fusion, and The OmniGroup. And then there were a lot of very small shops and single developers releasing great products. One of the challenges that the Office:Mac team had when I was there was the dearth of software engineers who had both Mac development experience and very large codebase development experience.
Both the platform and the development community have evolved, resulting in significant impacts to independent developers. As is obvious from the near-impossibility of getting WWDC tickets since it first sold out in 2008, the Apple developer community has seen an unprecedented influx. Companies large and small have added iOS developers. Independent developers have flocked to the platform.
A major point of change has been the App Store, first for iOS and then for Mac. The proliferation of apps has made app differentiation difficult for developers, whether they are a large company or an independent developer with a great idea. To attempt to gain users, not only has there been a proliferation of apps, but those apps are likely to be free.
Free apps are, of course, not free. Apps require developers, and developers have bills and a desire to keep paying those bills. For a large company, the cost of developing a free or inexpensive iOS app is often absorbed in the costs of developing other products that are well-funded and that the iOS application supports. The App Store has evolved other methods for developers to make a living, including advertisements and in-app purchases.
Which leads us to the state of the independent developer. It was possible to be an independent developer and make a decent living at it. Some developers, through a combination of skill and luck, found themselves doing more than just making a decent living. As the price tag of applications has trended towards zero, it’s been ever-harder for an independent developer to be only an independent developer. A good idea for an app, the skill to develop a great app, and a sprinkling of luck is no longer sufficient to make a decent living.
Independent developers often have to diversify their income. They might have to keep their day job and work on their app on evenings and weekends. They might have to become writers or podcasters to ensure that they have sufficient income. They might become developers in a corporate environment, taking advantage of all of the iOS developer opportunities that are available now.
I was overjoyed to see Samantha Bielefeld‘s take on the state of independent developers as she considered Marco Arment‘s move to make his iOS app Overcast available for free with an optional patronage model. Her point that he is able to try this as a result of his unique position in the community and his other income streams is one that resonated with me. If a well-known and well-regarded developer isn’t reaching an audience with a well-designed and inexpensive iOS app and thus chooses to make it free, what about everyone else?
It’s distressing to see a well-known independent developer seemingly throw in the towel on independent development. It’s doubly distressing when that independent developer doesn’t seem to understand that the model of patronage isn’t necessarily one that will work for independent developers at all, let alone ones who don’t have thousands of Twitter followers or close friendships with well-placed members of the tech press.
What is the state of our community? Are our options limited to either working for a big company or hoping that ad revenue continues to limp along? How do we have a vibrant community of world-class apps and developers creating those apps if our users have become conditioned to free apps?
These are important questions for us. Attacking Bielefeld for asking important questions is the wrong thing to do. For all of us, whether we’re in big companies or independent developers, we have to consider our place in the community and how we’re supporting both ourselves and the long-term success of the community. I’m hard-pressed to see how this constant drive to zero is going to ensure our long-term success. We must stop shying away from important and difficult questions, and we must stop attacking anyone who questions this status quo.
Google’s Tech gCareer Program
This looks like a great program out of Google that directly addresses some of the problems that women face in their mid-careers.
Google’s Tech gCareer Program is a 3-month program open to all qualified Software Engineers who have taken a break from a Software Engineering position at a high tech company. The program will provide participants with tailored technical training to help them bridge their knowledge gap as a result of extended leave. In addition to skills-based training and programming projects, cohort members will participate in professional development and mentoring sessions aimed at supporting their transition back to work.
Knowing how data-driven Google is, I hope that they will share how many people who go through their program are successfully able to get back into (and keep) a software engineering career. If it’s successful, perhaps they’ll extend outside of coding too, and perhaps we’ll see other companies create similar programs.
Gmail gives the cloud a bad name
The cloud isn’t always an easy concept for people to grasp, even before we add in complexities like public cloud versus private cloud versus hybrid cloud. For a non-technical audience, I usually use webmail to help them understand the cloud. I can login to Yahoo! Mail, or Outlook.com1, or Gmail, from any computer in the world, and I’ll see everything the same on that webmail service. Since there are lots of webmail users, starting off with a known concept and explaining how it’s one type of cloud helps them grasp the idea.
The problem is that webmail in general, and Gmail in particular, is a public cloud. It’s a public cloud that you’re not paying for. Servers, storage, and bandwidth are not free. To pay for the resources that Gmail needs, Google shows you ads that it thinks are relevant to you. But now, Google has explicitly said that its users should have no expectation of privacy:
Just as a sender of a letter to a business colleague cannot be surprised that the recipient’s assistant opens the letter, people who use Web-based email today cannot be surprised if their emails are processed by the recipient’s [email provider] in the course of delivery. Indeed, ‘a person has no legitimate expectation of privacy in information he voluntarily turns over to third parties.
Users can have a legitimate expectation of privacy of information that they voluntarily turn over to third parties. There’s plenty of data that I voluntarily turn over to a third party. Every conversation that I have with my doctor or my lawyer contains data that I’ve voluntarily turned over to them, and I have the expectation that they’re going to keep that information private unless I authorize them to do something else with it (say, use it anonymously as part of a medical research study). As a researcher myself, I get lots of sensitive data from the participants of my research, and I’m very careful to ensure that my participants’ sensitive data is not revealed to anyone. When I’m reporting results to my own team, I would never say “Eddie Dinel, Director of Program Management at VMware, said …”. Instead, I always say “Eddie, a senior manager at a technology company, said …”2. I make sure that the information that participants share with me is kept private.
If you’re using a cloud for sensitive data, you should be careful to understand what the privacy policy is of that cloud. Gmail has told you that you can’t expect privacy from them. This might or might not change your usage of Gmail, but don’t assume that their stance on privacy applies to every other cloud out there.
irony has a new definition
You should go read this post to fully understand the new definition of irony.
good jobs vs good husbands
In the New York Times obituary for Yvonne Brill, she is quoted as saying, “Good husbands are harder to find than good jobs.”
I think she’s got a point, although I think that there’s also a difference of expectation between jobs and husbands (good or otherwise).
| jobs | husbands |
|---|---|
| can change every 3-5 years | generally frowned-upon to change every 3-5 years |
| can look for a new job while still holding my old job | dating while married isn’t generally acceptable |
| leaving a job needs two weeks of notice and a little bit of paperwork | leaving a husband requires (at least) several weeks, a lot of paperwork, and a lawyer |
| can accept a new position because it’s an awesome opportunity | taking a new husband because it’s an awesome opportunity would earn me the label of “gold digger” |
| can try out something new and go back | can’t try out a new husband and go back to a previous one1 |
| a software engineer who has 7 different jobs in the course of their 40+ year career is normal | a person who has 7 different partners in the course of their 40+ years as an adult is not normal |
I’ve got a good husband, and we’ve been married for nearly 4 years. By Silicon Valley job standards, I should be out hunting for a new one, but I think I’ll stick to societal standards instead of job standards on that one.
- Even Liz Taylor, who did marry Richard Burton twice, didn’t have an intermediary husband between her first and second marriage to him. ↩
college versus software engineering
There’s lots of things that you do as part of your job as a software engineer that you don’t learn in school.
When you’re first starting out as a software engineer, you probably don’t really know what it’s like to work on a team. You might have had group projects in school, but their scope was limited to whatever you could accomplish in that semester, you’re working on it from the very beginning through to its completion, and everyone in your group had roughly the same amount of experience that you do. This is very different than delivering real software.
In the industry, you usually start out working on a project that’s already in progress, and if it’s software that’s been available for more than a couple of years, it’s got a history that you know nothing about. You have to learn where the project is today, you have to learn how to contribute to your project, and your deliverables or your deadlines1 are going to change at some point. You’re virtually guaranteed that you’re not there for the beginning of the project, you’re coming in to complete the work that someone else has defined.
There’s often not an actual end of a software project. You finish this version, you start working on the next version, and you have to go back and patch bugs from this version while you’re working on the next version. At some point, you’re going to stop working on this project (either moving to a different project in your company, or moving to a different company altogether), and the project is going to continue on. This means that you’re going to have to figure out how to help whoever is taking over your work understand where you are and what needs to be done next.
Your project team is probably bigger than the ones that you had in college, and there are more roles on it. Your college project team probably had everyone contributing code. Now you’ve got to figure out how test fits into your world, and program management, and documentation, and user experience, and then there’s this marketing person that suddenly appears and you don’t know what this means. In addition to all of these specialized roles that you haven’t had to deal with before, you’re also working with a much higher degree of variance of experience. In college, everyone probably had roughly the same level of experience. When you’re delivering software, you’ve got everyone from fresh college grads all the way up to the person who’s been working on this software since it was first shipped N years ago.
Deadlines are fixed in your college project. You know exactly when the semester is going to end. You might decide to change the scope of your project when you realize that you had planned more than you could actually fit into the semester, or when the person who said that they’d do this important piece of code never actually came through, but the deadline is immutable. When you’re working on on a software project, you’ll learn very very quickly that your deadline can get changed without any notice.
Also, your project might change mid-course. When you’re working on a project in a college course, you don’t have to worry about your competition changing, or about the market suddenly deciding that this new technology is an absolute must-have. That list of features that you thought were going into the next release can change at any time, and it probably will. Not only are you going to have to accept this change, but you’re going to have to accept that a feature that you were working on yesterday that was very important might not be important tomorrow. In fact, you might stop working on it entirely so that you can work on something else that’s now more important. That’s okay, it’s the nature of the business.
None of this is meant to say that group projects in college courses are useless. You learn a lot by having to work with other people to get your project done, and that does translate well to your first software engineering job. What you learn in your group project in college is limited, and doesn’t give you the full story of what you’ll experience when you start working for a company on a software project.
- Note that this isn’t an XOR. It’s actually most likely an AND, but I’m going for OR because OR doesn’t preclude AND. ↩
free Smalltalk books
My first love in computer science was programming languages, so I’m sure that you can imagine how my little geek heart turned cartwheels upon finding Stef’s free online Smalltalk bookcase. I have some downloading to do …
software costs money
In light of the news that the Sparrow guys got bought out by Google, there’s been a lot of hand-wringing. Comments threads about this news have been full of people whinging about Sparrow “selling out”. But here’s the thing: software costs money. People who make software are a relatively rare breed — and I’m saying this from Silicon Valley, where we’ve got to have a higher concentration of software engineers than anywhere else in the world.
It used to be that you’d spend a hundred bucks or more on software. This is still true in rare cases: Amazon says that the cheapest version of Office:Mac is $100 (the version with Outlook adds another $50), OmniGraffle costs $100 from the App Store. Sparrow rang in at $10, or $3 for the iPhone version, and I saw plenty of people whinging about its high cost.
Software does not just magically occur. Good software takes a lot of time and expertise. If it were easy to create good software, there’d be a lot more of it out there, and I wouldn’t’ve burnt so much time trying to find a reasonable replacement for Quicken for Mac1, or a desktop calendar app that supports CalDAV2. For software to be really good, you need the following:
- a software engineer or two
- a tester or two
- someone to write the documentation3
- someone to make sure that your application’s architecture supports future growth
Now, in some cases, you can get away with all of this being the same person. But that’s a lot of work for a single person. It’s a lot of work for multiple people if the app gets complex enough, and I’ll tell you from a lot of experience that a mail app like Sparrow is a lot more complex than is obvious on the outside4.
But let’s just assume that this is a single software engineer. There’s two ways to go about this. You can do it in addition to your day job, which means that you don’t have a lot of time to focus on your side project, and it also means that you’re giving up much of your personal life so that you can have this side project going. Your day job pays your bills, your side project is something that you love and think is awesome, and that you really hope will take off enough one day so that you can quit your day job. Or you can quit your day job and try to live off of savings for awhile (or your partner’s income, if applicable), and work full-time on this so that you can make it into something self-sustaining.
Neither case is sustainable unless the app really takes off. And by “really takes off”, I mean “can pay your bills at least as well as your day job”.
The other thing is that consumer software sells in cycles.5 You’ve got two major events where most of your software is sold: one in the late summer as students prepare for the upcoming school year, and one late in the year for holiday shopping.6 You’ll get another spike for a new version, but most software doesn’t have a new version every year, and software vendors often try to time their new versions to line up with either the school or holiday shopping seasons to take advantage of the time when consumers are already in the shopping mood. Smaller spikes occur, such as when you get some good press from a positive review, but usually reviews are clustered around release time. So you make most of your money during those two spikes, and that money has to last throughout the whole year, plus help you make investments on the next version.
At some point, we as consumers stopped wanting to pay money for software. Some of that is that our computers were bundled with a lot of software so that we didn’t have to pay for apps that we use every day, like mail apps and web browsers. Some of that is that companies who don’t primarily make their money elsewhere (say, on selling you computers) started selling their software at a steep discount, which depressed the overall market. Some of it is that some software is now supported by ads, which reduces the out-of-pocket expense for the consumer (although there’s obviously the cost of having to view ads all the time). And some of it is just that we as consumers have become a lot of whiners who have come to think that software should just come to us magically, continue to work on any hardware that we buy, and get updated with new features regularly.
David Barnard at App Cubby wrote a great post about this called The Sparrow Problem, which discusses his own experiences in selling software via the App Store and includes his own back-of-an-envelope calculations about what it takes for an app to be sustainable for an indie developer.
I don’t blame Sparrow for accepting a Very Large Cheque from Google. They hit the hard reality of software development: software costs money. For the software developers, there are always bills to pay (both their own and those associated with making the software). A good software engineer is never lacking for offers to go elsewhere, because good experienced engineers are hard to come by, and software recruiters are relentless7. There’s always an opportunity cost associated with spending your time on something — you could be spending it on something else and, quite possibly, making more money in doing so. When you’re not making enough money on your application to be self-sustaining, it’s not hard to understand why they would accept that Very Large Cheque.
And I say: good on ’em. Gmail could use the talent of some smart IMAP and UI engineers. Google made a good decision in buying them out, and I think that Sparrow made a good decision in accepting their offer. I hope that Gmail improves because of it.
- My final answer: Fusion + Windows 7 + Quicken for Windows. None of the Mac-native apps came anywhere near covering my use case. I’m not happy continuing to support Intuit, but they’re the only ones who support my use case, and Quicken for Windows is so much better than Quicken for Mac. ↩
- iCal sucks, BusyCal isn’t quite there yet but is a lot closer. I was happy to pay the $50, since that was much cheaper than whatever hospital bills I would have incurred when I stabbed my eyes after using iCal for too long. ↩
- Even if it’s just the tooltips on the screen, otherwise you end up with useless tooltips ↩
- IMAP isn’t a very well-written standard, resulting in a lot of work getting your client to work with the various IMAP servers out there. If you start off by focusing on a server that doesn’t do a very good job following the not-very-well-written standard *cough*Gmail*cough*, then you’ve got a big job ahead of you in trying to extend your client to other IMAP clients. ↩
- Disclaimer: This is my experience from working at Microsoft on Office:Mac. I don’t work on consumer software at VMware. ↩
- Black Friday isn’t good for just retailers. It’s good for software vendors and others who are selling their merchandise through retailers, too. ↩
- Which reminds me – I should write a post about the clueless recruiter who recently contacted me. ↩
using VMware Workstation to thwart a fake antivirus scammer
I’ve gotten a bunch of fake antivirus/malware scammers calling my home lately. Like others, sometimes I take delight in stringing them along, playing dumb while they try to get access to my machine. Sometimes, I’ll ask them, “What’s Windows?”, waiting for them to figure out that I’m not actually a Windows users at all. Or sometimes, when they tell me that they’re from Microsoft, I’ll use my old Microsoft credentials and say, “wow, I wasn’t aware that we were being more proactive about this, I’m so glad that our company has decided to do more to eradicate malware”. Once they realize that they have someone technically adept on the call, they hang up instantly.
But I’ve never strung them along like this. A couple of weeks ago, one of these scammers cold-called a security researcher from Sourcefire. The security researcher immediately knew that it was a scam, but he decided to take it a step further: he quickly set up a virtual machine for them in VMware Workstation, and let the scammer go to town: “I realized I could give them an environment to bang around in”. So the scammer installed LogMeIn, and then he watched (and, yes, captured video) while the scammer disabled Windows Services and VMware services (but not actually realizing that this means that he’s in a VM!), all the while insisting that he’s removing malware. Then they force a reboot under Safe Mode, which (given that they’ve disabled everything) won’t work properly. This is how they try to get the victim of their scam to freak out and give them their credit card details, and likely will leave the victim with a computer that won’t work at all unless they can find someone else who can figure out that it’s simply that Windows Services have been disabled.
Dark Reading has a good breakdown of the security researcher’s call, and a shortened version of the call is available on YouTube.