You start work on a new mobile project, there are some technical challenges, it’s going to look cool and be a useful app. You are excited, you can’t wait to open Xcode and select ‘New Project’ giving you a blank canvas to create something beautiful and wonderful.
Fast forward to the end of the project (way later than you originally anticipated)
The app is slow… or the app crashes… or the app won’t install on some devices… or the app looks weird on some devices… or the app doesn’t even do what you expect.. unhappy users, stress and you feel like a bad developer.
Every developer that has been in the game long enough has stories like this. Every developer also has that one nightmare project that still gives them nightmares. Mine happened around eight years ago. A two week project that turned into three months, a fixed price project (priced very competitively to win the business) that almost made me rethink my life plans, after dragging myself through it for less than minimum wage. One thing I have learned is that there are always going to be problems with some software projects, that is the nature of the industry, this is not simple work. If you stick to some rules and principles though, you will mitigate the number of problems you can have that will protect you (as a developer) and the client (sometimes they need protecting from what they don’t know).
1. Lack of detailed planning
Here’s the simple truth. Even a relatively simple app can be difficult to develop across different platforms and devices, if you don’t plan enough and take enough care. Most developers want to start coding immediately and create the ‘development plan’ as they are developing. Before coding starts, a development spec should be completed. This should detail every technical aspect of the project, and should have sign off by every stakeholder on the project- it’s really important for everyone to agree on what is being built. Without a well thought out development spec a client could be asking for a red Testarossa but could find a pink Prius on their driveway…
2. Poor Communication between stakeholders
By stakeholder I mean anyone involved in work or decision on the project. This communication starts with the development spec and everyone being in total agreement (see item 1). Software projects are agile, they have to be because requirements change (shock) and the requirements are not always correct at the start (double shock). If we know there is a good likelihood that the project is going to have to deal with unexpected changes then we need to know about them ASAP. To get stakeholders thinking early and often, they need to be involved in the development process in terms of development updates. If developers are telling everyone involved what they are working on and what they are doing next, this can stimulate people to think about the project and potential problems with the current approach. There are many tools out there that help foster communication, get everyone on Slack or Hipchat (to name a few) and broadcast updates to the entire team as the team is moving through the project. These tools allow one on one communication, or communication to groups that you can create. Oh, and never assume anything. Ever.
3. Get the architecture right first time
The client has asked for iOS and Android, no problem you think, I will just use a cross-platform development tool. You quote a month as in your mind you are thinking one code-base. One week in and you get to that low level functionality where you have to, say, manipulate video on the device and you have that sinking feeling that you are going to have to write a native app – and develop two versions in double the time.
If you have a detailed development plan this stage is much easier. Looking at your development plan you will be able to analyze where the potential risk is in the project. Anything that is not standard coding and requires research, should be de-risked. That means you figure out your approach before starting any coding. During this initial research it will become very clear, what technology you can use to help your development efforts (for example a development platform). If you are making assumptions with the architecture, test it out, before starting work on the mainstream development.
4. Get the right team
This is a rule that is relevant for in house development or outsourcing to a development shop. You can have great people on the team, but not the right people in the right place. A great web developer is not necessarily going to do a great job on a Cordova project or a HTML 5 hybrid app. Project complexity, if drawn on a graph, should have a line that follows it for developer experience. The more complex a project the more (relevant) experience a developer should have. You also have to be careful with developers, ask an android developer if they can develop on iOS and most will say yes. Developers want to learn new things, which is great, just be careful where you are letting someone cut their teeth with new experience (not on something critical to the project), and build this learning curve into the project plan. Lastly, a project manager is a great idea. Someone that is not a developer and is the interface between the developers and the client (internal or external).
5. It’s about User Experience
Harsh fact- most developers develop for themselves, and they want it to work for them, secondary (or way down the list) is how well it works for the user. If the user experience is right, the end user won’t use the app, it’s as simple as that. User experience is also something not related to development. It’s a great idea to have someone involved in user experience that is not a developer and not on the development team. The requirement for this should be built into the design doc from the start, but it also needs to be monitored throughout the project. This person should be taking development builds and trying features out as they get added. The project manager or preferably someone outside the team should conduct usability testing with focus groups or within the target market of the customer whom you want to press that download button once the app is available.
Hopefully this will help guide you down the path of app glory and keep you from falling off the software development cliff. To your success.
You must be logged in to post a comment.