It’s busy period always before Christmas. Clients have ideas and request, we [at 2dwarfs] have started projects of our own, so we have interference. And although it’s always much fun to develop projects of your own (I’d be dishonest and lying if I say otherwise, ask anyone), we must stick to our professional ideology of building trust with the clients, coming across their needs. Anyway, we are slowly finishing what’s been the busiest November the past few years and we have some experience to share with you. And why do we want to share it? Because we believe that sharing is what makes technology move forward, either an idea, experience, source code or motivation. And we hope it’s obvious we strongly stand by that.
What’s sometimes a month of finishing a project, for others is 2 weeks of hard work and 2 weeks of creating and fixing frustrations. And why would that happen, well it’s because of something more or less, everyone in the process is involved with. Whether is the project management (which, trying to be defensive here, most of the time in our case is someone at our client’s side), whether is the development process (and that is us resolving constraints, change requests, broken laptops, ousted networks), or is the indirect client (which comes as the client of ours client) changing the requests for the software you develop.
I have the feeling that many times mobile development is underestimated by its size only. It’s mobile application, what can go wrong? Well many things. And if you change one brick while the walls of the construction are built, you get a tilted house. Luckily we are joyful whenever crap comes our way because we learn and that is something we did this last period. We had our notes applications on, writing down notes from the process until the final solution was reached. More or less they are notes of frustration and I apologize from the very beginning about the tone you may face here, but see it as my shrink, a therapy. Let’s go one by one.
‘But my caching implementation!!!’
Ask for specification or functionality list and you will be more successful at the end. Why? Because you will be able to bring a solution that will cover every connection of the final product. It will reach to every entity of the skeleton making it adaptable to changes, expansions and further (new) features. Yeah, that sounds nice but it’s not always the case. You get the idea described in email and you understand it, you know how to develop it, and as the deadline approaches the frequency of emails from your client grows. ‘Let’s put more spacing here…’, ‘Let’s make it thinner’, ‘..let’s make it more yellow’, etc. You get to deal with small screwups forgetting to finish something bigger and more important. And yes, the user (or the client) is not the one that will be happy with your caching code that runs behind, no matter how cleverly developed it is. The only one that will be happy and satisfied with such feature for the first versions is you only. Until the client understands the importance of having great architecture behind the application, don’t expect him to be happy about it and pay less attention to the bouncy animation you implemented in 10 minutes. That is why it’s important to have something more than a version of the application for some other platform, browser or system. It is really important to tell the client that the wireframes are not enough to develop everything that’s hidden in his head. What’s hidden has to go out and transform into functionality list that will be followed during the development. It might sound as the perfect scenario which has never happened to me anyway, but at least that is what I believe is the right way of software development. Once you have the specification for the software, lock it!
‘Make the spacing same as here…’
Lock the list, put the key in your throat and swallow. If the development process takes 4 weeks, do not unlock this list until the final week (well ok then magic happens and you’re fscked!). Try to answer politically to any question that starts with ‘can…’ while these 3/4 of the time of the development last. ‘Can we make it bigger…’, ‘yes, we can but after the main development is finished’. Other’s would go further and be arrogant, ‘Can we make the app more optimized?’ -‘No you cannot, but I can in the bug fixing period’. Whatever your attitude is. Just demand for a lock of the features list while you’re developing the backbones.
‘…well, the app looks too small on iPad!’
Do you ask whether the app you’re about to start developing should be supported for different hardware platforms? The ‘mobile’ would not be the only case when you should ask this, but in general, any type of development? Have you ever got a ‘remark’ that the software you created was great but it’d be much better if Internet Explorer was covered, or Mac? Or the latest iPad? Well, if yes, it’s your fault. Not defining the apps’ scope is common mistake made by many and again, the fault goes only to the guy that is developing the project.
‘But it’s slow!!’
Fragmentation. Really important issue when it comes to Android. Oh boy, the clients will find the crappiest devices out there. And will tell you your work sux because ‘this view is overlaying that view’ (and also if you come across those with negative attitude to the technology you develop for then it gets even worse). Yes, Android has so many flavors, versions, subversions, custom ROMS, it runs on so many devices in Europe, Asia, America… it’s, more or less, cataclysm. Many Android developers know how painful is to cover Android versions from e.g. Gingerbread (>=2.3). Why? First, because many old device got update to 2.3 and because many parts of Android’s API suck when compared to new those in the latest SDKs. There are technical examples that I would not like to mention (for the sake of readability) when one block of code works like ‘this’ on Gingerbread and like ‘????’ on Jelly Bean. It’s crazy. And then you have the expectation that the massive memory consuming application you develop would work on every device out there, starting from the first Android device up to Nexus 4. Nope. You cannot do that. Because Star Craft 2 would not work on my P2 from 1999. That’s why.
Limit the set of devices and then limit the hardware specifications by CPU and RAM of the device. Trust me, you’ll save lots of frustrations, lost nerves and white hair while developing for Android.
‘I can rename the file to header.9.png if you want?’
Whether it’s a music file in a format not supported for the platform you develop, or a graphical resource (icon, background, color), always get the assets for your platform from the client. If not, well, charge for creating ones.
It’s not a big deal for any developer to create a 9patch background by yourself. But that is not what you’re supposed to do and I know it’s no fun to do it. But then you have 100’s files that were used for previous projects and it’s expected that the same ones would work with your project. Yes, I know the pain Android developers, when you’re supposed to port that app on Android and you’re given the non-proportional, weird and twisted graphics without its states (pressed/clicked/normal), expecting that you’ll make them work since well, ‘they work on iOS, so what’s the big deal?’. Throw that away. Ask for Android specific assets. Ask for assets for the platform you develop for. And yes, the same can be applied for iOS developers that get Android resources from their clients. Just ask for assets which are applicable to iOS projects.
‘People would say, what looks good when shown in IE?’
One thing you have to respect. The tools other people make money with. I am really attached to my laptop and whenever someone says bad things about it being a small, lousy and slow model makes me mad. Well ok, mad inside. Because that is the tool I make my money with and so far it works just fine. I don’t mock your spreadsheet tables so stop mocking the platform you’re ordering software for. Whether it’s iOS, Android, Windows Phone or any of the many desktop operating systems. It’s not the platform that makes the software bad. It’s bad planning, bad implementation, bad graphical designer, bad idea. Bad professionals. The ‘do it yourself if you can better’ is the best answer to conclusions like ‘crappy Windows Phone’ or ‘ugly Android’ or ‘bloated Ubuntu’.
Much easier now everything is out. I am not saying that developers should be arrogant and rude (well most of them are whatever I am saying). I am just trying to explain that developers, just as any other professional, should stand by what they are doing because they know it best. Otherwise other people would not put money in them. And if they know it best, they should set part of the rules of playing.
Reference: The frustrations of the development from our JCG partner Aleksandar Balalovski at the 2Dwarfs blog.
