Being a software developer isn’t easy. But nothing rewarding ever is. Still, it’s good to know what frustrations lie ahead as you imagine a career in software development.
One of the biggest frustrations you’ll face when working as a software developer is dealing with the sheer number of different platforms you have to develop for.
You’ve got iOS and Android.
You’ve got four major browsers.
Not to mention, you’ve got innumerable different versions of each of those half dozen platforms.
It’s a nightmare!
But it has gotten better.
Gone are the days of having to develop for Internet Explorer 6, the single biggest headache for software developers for the better part of a decade.
And there are lots of tools, like React Native, that help you develop effectively for both mobile operating systems simultaneously.
But there are still tremendous hurdles to overcome to make sure that your application works identically across all of the different platforms.
One of the major hurdles is simply being able to replicate behavior that users are seeing.
If someone is having trouble with a Samsung Galaxy 7 running Android version 7.1.2, odds are you don’t have that specific device or even access to it.
(Again, there are tools, like Browserstack or XCode or the Android Emulator, to help you try to replicate those devices from your machine, but they’re never perfect.)
The only viable solution to try and solve these issues is to have the user record video of their screen to show you exactly what they’re doing and exactly what’s happening. Then it comes down to reasoning about the issue and trying to figure out what might be happening, without being able to actually test it natively on the device.
That can get pretty frustrating.
Testing is hard. There’s no two ways about it.
First, when you’re developing an app, you inevitably become an expert at using the app just by the very act of building it.
So it can be extremely challenging to get into the mindset of a user. When you actually see people use your app, you’ll constantly be wondering, “Why are they doing that? Why aren’t they doing this?” But you are not your user. The problem is with your interface, not with them.
So you have to involve other people in the testing process, but therein lies another frustration.
People aren’t naturally good at testing.
Often the feedback you get isn’t what you’re looking for. One of the biggest problems here is what we call “pixel pushing”. You’ll get feedback like “this section should be moved up” or “this should be a different color” when what you wanted is for them to test out whether a certain piece of functionality works.
There are ways around this.
One important thing is to have a definite script for testing so you can tell the folks testing your app to follow explicit steps and to give feedback on just those steps.
Another thing to do is to be explicit about what kind of feedback you’re looking for. Divide your testing up into three phases: functional, enhancements, and feature requests. For functional, testers should answer “Does it work?” For enhancements, testers should answer “How could it work better?” For feature requests, testers should answer “What else should it do?”
With software development, you’ll be constantly faced with novel requests. The trouble is, folks will want estimations on how long those novel requests will take, but by the very nature of their novelty, you won’t be able to give a good estimation.
As an analogy, consider the moon landing. Kennedy wanted to land on the moon within a decade. NASA said it was probably possible. It turns out that it was (and it turns out their estimate was incredibly accurate – maybe a case of self-fulfilling prophecy?) But nobody had any idea whether it would take a couple years or a couple decades.
You’ll have hunches about how long something will take just based off of how long similar requests have taken in the past.
But the details matter.
The more detailed you can get about the request, the more accurate you can be with your prediction. Details provide limits, and limits make it easier to estimate what the actual scope of the request is.
Speaking of scope.
Scope creep is when the initial set of requests starts to be overwhelmed by a slew of new, incoming requests.
You start with an idea of a project (and how long it will take and what it will cost) and all of a sudden, a couple months later, the project has morphed into something else with no end in sight.
We’ve seen it happen over and over (and over and over) again.
And it’s hard to not let scope creep happen, because there’s really no good answer when a request comes in after work has started for additional functionality.
You can say yes, and then you’re doing work for free and giving away hours of your time.
Or you can say no, and anger your client who will frustrated you can’t just add in some new feature.
So scope creep is almost an inevitability.
But with that in mind, the best band-aid for scope creep is to simply budget for it, both in terms of time and cost. You know that the project is going to extend beyond what’s initially asked for. It’s going to happen. So make sure you have enough time and money to accomplish the unavoidable scope creep.