July 2019 | Mood Up team - software house
illustration of sad looking broken phone

Does your App need an update? Check for these 7 signs

Reading Time: 5 minutes

 

With almost everyone scrambling to deploy an app to bring their services closer to the customer’s fingertips, your app must be top of the line, have great functionalities, be smooth and have a great UX if it is to make its mark. Sounds like a tall order? That’s because it is. 

Developing a great app isn’t rocket science, provided you do your research on the end-users. Such apps must be customer-centric (we cannot reiterate this enough) and be developed with your customers (think usability tests). Doing so, as you can imagine can be rather costly as it involves many hours of design, development and testing before you can finally release the app. You must then focus on marketing your app to ensure your app gathers traction with your users. That’s it, right?

Not quite, as the business landscape your app would be operating on is bound to change very fast, requiring the app to stay ahead of the curve. This is why we recommend our clients to set aside a portion of their app development budget for upgrades that can preempt new customer requirements. 

Need further convincing? Take a look at how your peers think and compare your app against these 7 traits of outdated apps.

Graph 2 how often businesses update app pt. 2

1. It lacks the latest functionalities 

One of the simplest reasons you might want to consider updating your app is to add new functionalities to it. Doing so gives your end-users what they want, preventing their migration to other apps, whilst attracting new users who will contribute to boosting your bottom line. Such updates impact the experience your users would have within the app and might open new revenue streams that just might be the break your organisation needs. 

A fantastic example of this is Facebook Owned Instagram, who started replicating the exact features Snapchat offered in its app in a bid to lure young users to it (after a failed bid to buy it in 2013 for $3 billion). The strategy worked as Instagram stories now see 400 million daily users whilst Snapchat who introduced the stories feature and considered it a key differentiator is now at 191 million users. 

Another interesting development you might want to keep an eye on is Instagram’s IGTV which might prove to be a worthy rival to YouTube. 

2. App performance is declining

The success of your app is dependent on its performance, which is why it’s important to go dig into the quantitative data. We encourage all our clients to have a set of metrics through which they will be able to measure the performance of their app, and set benchmarks through which the performance could be measured. A few of our top performance metrics include but are not limited to

  • Active users – the number of users who use the app in a set period of time 
  • Session time – time spent on the app
  • Uninstalls – the number of users who uninstalled the app
  • Crash rate – even a single crash is unacceptable. An increase in this is definitely a push to upgrade your app

The above quantitative metrics will inform you of the decline in performance and therefore the existence of an issue. Finding the exact issue, however, is only possible through qualitative data gathered through your interactions with the customer and observations of user behaviour within the app. 

prisoner meme about app crash rate

3. Your users have trouble navigating 

Most apps have set design standards that provide users with a sense of familiarity and intuitiveness when navigating their way within the app. A break in this can have the user feeling disoriented and at a loss on how to use the app, impacting the overall UX. This will then cause a decline in the app’s performance, driving your hard-earned users to rival apps.

Can you imagine an app that doesn’t stick to Google’s Material Design being a hit? What about one that goes against Apple’s Human Interface Guidelines? 

Remember, the hardest battle is retaining your users and not gathering them

4. Reviews/requests from users

The best judge of an app is its users, which is why we encourage our clients to pay attention to reviews on the App/Play Store. Another way through which you can supplement this feedback is via the gathering of in-app feedback. 

A sizable amount of negative feedback or weak ratings on your app should give you pause and deserve a closer look at what is amiss. Such feedback is essential to establish what is working and what is not so that you know the actual scale of the upgrade that is required.

Similarly, you might find a sizable number of users asking for a feature that deserves consideration. Deploying an upgrade with such a feature will allow you to be seen as an organisation that listens to its users and create a positive impression with your end-users. 

5. Your app doesn’t follow the latest security protocols 

With security breaches divulging user information on an almost constant basis, there is simply no reason for your app to be behind the latest security protocols. Remember that an apps owner is solely responsible for any breaches and can be held liable for any damages caused to the users. 

Such breaches also dampen the trust your users place in you and can cause irreparable damage to your brand’s reputation. Remember Facebook’s Cambridge Analytica data scandal? How about Yahoo who had 3 billion accounts hacked?

Meme on impact of GDPR on gross profit

6. Your app doesn’t support many devices

The goal of developing an app is to bring it to the hands of as many users as possible and is one reason you should support multiple devices. Doing so with new hardware devices such as tablets require the development of another version of the app, in order to ensure it matches the new display, graphics and device-specific features. 

Remember, your users should receive a very consistent and cohesive experience whilst using your app, whether it be on a mobile or a tablet. 

7. The codebase is long outdated

The codebase of an app is the complete source code that maintains its functionality. Such codebases usually contain a time interval after which they will cease to function as usual and should be updated over time in order to ensure its compatibility with your app’s operating systems. 

Such information is usually conveyed to a client by the software developers in advance and should be taken very seriously. 

Wrapping it up

App updates with today’s technology and lean development processes do not take much time as they used to. Investing is such updates will ensure your app remains relevant, boosts your bottom line and is a brand asset that will improve your ROI many times over. Doing it wrong, however, can have you experiencing the opposite as negative reviews create bigger waves and lasting impressions than those that are positive.

Are you ready to roll the next update for your app? Let us know how we can help you here.   

software tester pointing at a screen with code

8 Valuable Practices for a Better Code Review

Reading Time: 5 minutes

 

Code review is the systematic examination of a software product’s source code in order to discover mistakes that might have been overlooked in the initial development phase. Doing so allows the developers to rectify errors in the code as they are discovered, thereby improving the overall quality of the code. This, as you can imagine, is a rather exhaustive process in which the developer who does the review, reads the code line by line to check for bugs or potential problems in compliance with coding standards and best practices. Issues once discovered are communicated to the developer who did the original coding through email or tools such as GitHub or BitBucket. The image we found whilst reading Beller and Juergens (2014) does a good job explaining this.

code review process

Regular code reviews as we mentioned earlier brings a host of benefits to the project, the developers and the client. Provided below are 5 such benefits of code reviews that we at Mood Up see every day.

1. Help reduce bugs – A single overlooked bug can kill a project that’s been in the works for months for thousands of dollars. That’s why we utilise another developer to help discover bugs that might have been overlooked by the original developer. Such regular discovery of bugs allows the team to fix them and reduce the time the QA has to spend on testing.

2. Improve code readability – Delivering clean code is important in any software development project as the developers who take over a project with no prior exposure to it should be able to understand it speedily and not spend time trying to decipher it. Code reviews assist in this as they help improve the readability of the code by having a developer with fresh eyes go through the code.

Pro tip when hiring software developers– take a look at their previous code. Clean code is a good practice all developers must cultivate and is an indicator of their competencies.

3. Create a shared coding standard – There is no one way to solve the requirements our clients request of us. Some ways, however, are better than others and coding reviews from senior developers help to discover better approaches to solving problems. Such standards help to create shared coding standards, keeps us on our toes and create a culture of continuous development that is reflected in the code we develop.

4. Creates accountability – We perform our best when we are held accountable for our actions, and coding is no different. Code reviews ensure that the developers produce their best work in order to display their competencies to their peers. The developer who does the reviewing then does the same, creating a circle of accountability throughout the organisation.

5. Double-checks to ensure all coding requirements have been filled – Regular reviews of the code ensures that no requirements go amiss and all that’s required is what is developed. This also makes the job of the QA easier as some requirements are difficult to produce during tests and much easier to verify within the code itself.

chuck norris with gun meme about code reviews
He can, you can’t

So, how can you ensure a code review goes as it should?

1. Make your commit message as clear as possible – The commit message from the original developer should highlight what was fixed or added to the code, allowing the reviewer to verify it. It’s for this reason that we follow established guidelines when writing commit messages during code reviews.

2. Make and review only small pull requests – We use another developer to get a fresh pair of eyes on the code. A code review that goes for longer than 60 minutes and/or 300 lines of code, however, is tiring and defeat the purpose of using a fresh pair of eyes.

How do we know this? A study from SmartBear discovered that our brains can only process so much information, before the performance and the ability to find defects drops. This is why we recommend short but frequent code reviews.

3. Comment on the code and not the coder – Empathy goes a long way and is why it’s important to provide feedback on the code and not make it personal with snide comments. Doing so will ensure that the feedback on the code reviewed will be met with a positive response and encourage cleaner code in the future. This drives the collective code ownership that all organisations should strive for.

Butterfly man meme about feeling attacked by code reviewers

4. Describe a problem and give the solution – The code reviewers job is to find mistakes in the code and highlight it with suggestions on how to improve it. Personal preferences/opinions should play no part in this and is one reason why we insist code reviewers to provide feedback based on existing best practices and/or documentation.

5. Learn and share your knowledge – Code reviews as you might have guessed is a fantastic way to exchange knowledge between the committer and the reviewer. Such reviews, therefore, should be approached as an opportunity to learn something about the codebase, languages, frameworks and best practices. Doing so allows for the continuous development of the team, the code it creates and the company.

6. Comment only the code that was in the changelist – Commenting on every problem you see in the code and not just the ones in your scope is a good way to sour the relationship with the committer and reduce the velocity of your project. Commenting on the changes as they are being made is also a big nope as this can create an expanded changelist that includes many unrelated changes.

Dru meme about losing friends by code reviews 2
Don’t be like him

7. Approve code not when it’s perfect but when it’s perfectly acceptable – Being a perfectionist and criticizing every single line of code is not how you keep the developers motivated. Decide on what is really important and worth chasing as your task as the reviewer is to give the go-ahead for a working product. We recommend granting approval when remaining comments are for insignificant issues (like a typo) or are optional recommendations that you made.

8. Have a strong communication standard – A good strong communication strategy between the reviewer and the committer is important to ensuring the cleanliness of the code. We at Mood Up ensure this by asking both parties to confirm the receipt of a message with a 👍 or ✅. The committers are also encouraged to push back against any changes from the reviewers if they disagree with the changes requested. The reviewers should also give praise when the code is clean and congratulate on a job well done. Remember, positive reinforcement goes a long way.

To wrap this up, code reviews can be an exhaustive and sometimes frustrating process. The value it brings to the quality of code, however, is far superior and is why we integrate it into all the projects we work on. Doing so gives both the juniors and seniors of the company an opportunity to exchange knowledge and deliver a project that is bug-free to the client.

Computer with Node.js Django Spring Ruby on Rails logos

Which Backend Framework Is Right for Your Project?

Reading Time: 5 minutes

 

Any web development project is usually divided into two core phases: frontend and backend development. Frontend development refers to the development of all that a user would see and experience while using the app, whereas the backend handles functions such as data storage, security, scalability and data transformation. A good example is a car, whose body, dashboard and steering is essentially your frontend and define the experience you have with it. This experience, however, will not be complete without the engine, chassis and the fuel tank of the car (backend). 

A backend is vital to the successful function of any web development project, unless the webpage you require is a static one. The easiest way to have such a web page is to create one on WordPress as it allows for basic content and user management. Such a backend, however, is not useful for creating custom web applications with sophisticated requirements our clients require of us.

There are many backend languages used by developers around the world. A few, however, stand out for their ease of learning, use, development time and effort.

Node.js

Node.js is JavaScript runtime built on Chrome’s V8 JavaScript engine, allowing developers to run JavaScript code on the server. What is unique to Node.js, however, is its ability to serve data requests without waiting for the completion of another. This asynchronous nature makes it perfect for developing IoT web apps that send large numbers of requests to the server at the same time. Another advantage of using Node.js for the backend of a project is its ability to easily divide services to microservices, allowing large projects to be divided amongst the team.

What you have to also take into account is Node.js’s unopinionated nature, which gives developers little to no preloaded features when using it. The backend developers, therefore, have to start from scratch and spend more time to complete a project, despite the freedom that comes with it. Node.js is also not advised as a solution for projects that demand high computational power and require developers to keep their apps compatible with the constantly changing framework and libraries. 

The Node.js community however is an active one, with many developers from around the world contributing their projects for open source usage. One must, however, be careful as developers of lower skills have been known to use such projects in their work with clients, who end up with inferior products created from substandard code. Replacing and/or cleaning such code of dubious quality is expensive and is another reason we recommend doing some thorough research before picking a software development partner.  

Who uses it? Netflix, Walmart, Uber, Paypal, LinkedIn, Medium, eBay, NASA

Smart guy meme about stealing open source code

Django

Django is a high-level Python Web framework designed for rapid development and scaling. It’s very versatile and can be used to developing solutions for content management and scientific computing platforms. Django is also very easy to learn, understand, use and places an emphasis on speedy product development, making it ideal for small to medium projects. 

Django, however, is rather monolithic and does not allow for the division of a project into smaller parts as with Node.js. This might prove to be a disadvantage when working on large projects that need to be divided into several parts between developers. It’s also very strongly opinionated and does not allow developers much freedom as with Node.js. 

Who uses it? Disqus, Bitbucket, Instagram, Mozilla Firefox, Pinterest, The Washington Post

Austion powers meme on using Django

Spring

Spring is another successful solution build on Java, the most popular programming language in the world due to its object-oriented robustness. This popular framework for creating enterprise applications comes packed with many features and additions that allow a developer to start an application with a basic website and authorization, almost out of the box. Spring’s modularity gives developers the freedom to pick and ignore classes, helping them focus more on customer-centric development and less on reinvention. 

Spring, however, is very configuration dependent and requires a developer to write a sizable amount of boilerplate code in order to add new features. It also requires developers to undergo a steep learning curve as there isn’t much set standards and best working practices. This is one possible reason why you might encounter Spring when working with more experienced, bigger teams working on enterprise projects.

Who uses it?  Amazon, ESPN, VISA, American Express

For Christmas I want a dragon meme spring framework

Ruby on Rails

Also called “Rails” or RoR, Ruby on Rails is an object-oriented programming language that is fast gaining a name for itself. First extracted from another project due to a requirement of its author, RoR is now favoured amongst the backend development community due to its ability to create fast web solutions. It also allows for speedy development due to its convention over configuration paradigm, which essentially  “assumes” what the developer wants to do and how. 

The downside, however, is its relative recentness, which is why the RoR development community is not as large as those you would find with other backend frameworks. It’s also not very flexible and rather resource intensive when compared to other frameworks. RoR’s age also makes it evolve quite often, requiring developers to update several dependencies to ensure the product they created on RoR stays updated. 

Who uses it? Twitch, Github, Airbnb, Shopify, Bloomerang, Etsy

Dr Evil meme developers after convention over configuration

Which one should you choose?

The backend framework you need should be decided based on what you hope to achieve with your software product. This decision is best made by your software development house in close consultation with you, the project requirements, outcomes and future plans. Doing so is vital as the backend architecture you pick will decide the trajectory of development and have implications on everything from planning, design, development and testing

Need an application that is highly scalable, fast and supporting web, mobile and other devices? We recommend Node.js. Looking for a speedily developed MVP project that treats the web app and your backend as one? Go for Django or RoR. Have a computationally heavy app with a sizable number of features that require long development times and iterative developments with multiple sprints? We recommend opting for Spring as it allows for the division of the job requirements between a team and gives you control over what needs to be developed first.