Wednesday, 31 December 2014

Technology Radar for 2015

With 2014 drawing to a close and 2015 offering fresh opportunities it is up to every software development professional to look at the up and coming technologies which are becoming widely adopted. ThoughtWorks have released their technology radar for 2015 with a list of techniques, tools, platforms, languages and frameworks to either adopt, trial, assess or avoid in the coming year. This is well worth a read - I have to say there were quite a few which I hadn't looked at before - a prompt reminder of how quick it is to fall behind in this profession.

Here's my two tips for 2015 - the top technologies to either adopt or trial in any new projects you are working on.

AngularJS
AngularJS is an excellent JavaScript framework which when used effectively allows you to structure your code to make complex web applications easily maintainable, and promotes code re-use. While the latest version (1.3) is extensively used in both small and major projects across the world, the AngularJS team are working on a re-write for version 2 in order to address some potential performance problems. The bad news is that version 2 is not a simple upgrade and will require people to re-write their apps. However, it is unlikely that projects started in 1.3 will need to upgrade - 1.3 is perfectly sufficient. Anyone starting a new project should consider closely whether they should start with version 2.


Docker
Docker has exploded onto the scene this year with people utilizing docker in both development environments and now production environments. Docker describe the product as follows:

"Docker is an open platform for developers and sysadmins to build, ship, and run distributed applications. Consisting of Docker Engine, a portable, lightweight runtime and packaging tool, and Docker Hub, a cloud service for sharing applications and automating workflows, Docker enables apps to be quickly assembled from components and eliminates the friction between development, QA, and production environments. As a result, IT can ship faster and run the same app, unchanged, on laptops, data center VMs, and any cloud."



With Microsoft working on supporting docker in the next version of windows server I think it's fair to say Docker is a major player in the fast moving software container field.

I'd be delighted to hear what technologies you tip to be big in 2015 - have a great new year!

Tuesday, 30 December 2014

Tutorial: Create great icons with Syncfusion Metro Studio

A key part of any website, desktop or mobile application is icons. These tiny little images can really bring your project to life and improve the look and feel of your apps. Choosing the wrong icon can have a huge impact on the usability of your application. I found creating or finding icons for my projects could be a real time waster - until I found Syncfusion's free desktop application - Metro Studio.

Metro Studio comes with over 4000 pre-made icons which you can customize to meet your needs - change the colors, change the size and export them to any format you want. Here's a quick run through of how to use Metro Studio.

When you open the application you will be shown a list of available icons to choose from:


Here you can browse by category and the search feature is great - finding similar icons. Lets assume we want a shopping basket and we select that icon:



The icon is shown (and defaults to your last configuration - so you can maintain color consistency). On the right hand side there are options for shape, size, transparency, rotation and color.



You can also create a project and edit multiple icons at once, great if using icons for buttons to ensure consistent styling.


There are various export formats for example bitmap, ico and png. A great tool to prevent stalling applications.



Tuesday, 16 December 2014

Situational Leadership in Agile

For anyone line managing as well as performing technical leadership, the term situational leadership may have come up in an HR lecture you really don't care about! Join the club.

However, this was once explained to me in terms that really struck home to me and is something that I have learned the hard way in my teams.

Agile works because the team is empowered to succeed - to a certain degree a lot of responsibility is delegated onto the team.

Situational leadership is the theory that there is no right way to manage - but effective leaders effectively bounce between styles. The styles are:

  • Telling/directing - the leader tells subordinates what to do.
  • Selling/coaching - the leader sells an idea so that subordinates will do it.
  • Participating/supporting - the leader will work with subordinates to get the desired outcome.
  • Delegating - subordinates are essentially able to pick up the work themselves. 


At its most effective, Agile works when most of the team are at the delegation stage. The team responds well to the responsibility and will work efficiently and take ownership of their tasks. This however can cause conflicts when the leader suddenly treats subordinates at the tell or sell stage. Why does he/she no longer trust us to do this work? 

This can usually be explained as either of the following reasons:
  1. The work is urgent and the leader needs to get involved closely to ensure it is done.
  2. The work is new or a change in direction in the team, and the leader needs to explain to the team why we need to make the changes. 
What I have learned the hard way is that you need to explain to your team this model so they understand why you are no longer delegating this specific task. If you can explain to the team you are currently at the stage where you need to tell for some reason, explain you are in the tell stage, why, and that normal service will be resumed soon and it will switch back to delegate. I find teams respond well to this and it removes any tension or hurt feelings in the team. 

Another thing that it's vital to remember as the team are acting in the delegate stage is that ultimately you are responsible. This means that even though you trust them to do the work, you need to take responsibility for it and that to do that you need them to report back with what they are doing and why decisions are made. Explain the situational leadership model to them and they will appreciate this. Reporting back to you helps you defend their decisions if they are questioned. 

The Tannenbaum and Schmidt's leadership model is a slightly different visualization of situational leadership but it explains the delegation/responsibility issue above really well.


Note that in the top right, the line never reaches the top right. That is because no matter how much you delegate, you as the leader/scrum-master/development manager are always responsible. Again explain this to the team and it will help resolve any conflicts.

Continuous integration is the key!

Continuous integration (CI) is a key component of any successful software development team - not just an agile team. Doing it right will bring the following benefits to your team:

  • Provide automated builds of software for testers to pick up. 
  • A common, repeatable platform to run tests (unit, integration, automated functional and performance tests).
  • A place to run code quality tools (SonarQube, FxCop, StyleCop, JSHint etc)
  • A place to create production build installers. 
There are various great tools for setting up continuous integration and you should spend time evaluating what will be best for your project. My personal favorites are: 
It is imperative that an agile team devotes time early in their project to get their continuous integration system up and running early (sprint 1 or 2) to ensure they have a solid platform to run on. Ideally your continuous integration will run on every commit into your source control system so that the team gets immediate feedback - have the changes compiled, have the tests run, is the code quality good. In the past in teams I have configured our continuous integration system to play a siren out loud in the office if the build has broken. The public nature of a central build location ensures extra care is taken by each team member when submitting their changes. 

For continuous integration you will need the following infrastructure at a minimum:
  • A server for builds, running the tests etc. 
  • A source control system (e.g. GIT, SVN, CVS)
For larger projects you may scale this up to have multiple agents running builds and tests. 

A common mistake teams make when creating their CI system is to not share knowledge of its workings with enough team members. Ideally everyone needs to know how it works - from developers to testers. These things need maintenance now and again and you want to spread the load, and have multiple people who can pick up the task. 


Once your continuous integration environment is setup and successful, you then need to look at automatic deployment - I'll write a future blog for this. Automated or continuous deployment is the next logical extension of your CI environment where you automatically build a new version of the system for test purposes perhaps or even automatically updating your production environment depending on your project.  Again with a little up front effort, the long term benefits can be huge!

Monday, 15 December 2014

The scrum meeting - some quick tips.

The scrum meeting is the key meeting in agile - it promotes communication and resolving issues and is very effective. Everyone does the scrum meeting slightly differently but the basic principle is that each team member answers the following three questions:

  1. What did you do yesterday?
  2. What are you working on today?
  3. Are there any blocks or impediments in your way? 
This is a very simple format which works great. However, it's important that you experiment with your team to get a system which works best for you. I find that I typically make the following tweaks with my teams:

  • I only run them every other day rather than every day - so Monday, Wednesday and Friday. This allows for work from home days (which I standardize as Tuesday or Thursday) to get maximum time in the office together. Daily scrums tend to feel like too much. 
  • The time for the scrum is the same every time - and it's first thing in the morning! Nobody like the morning, but I find it helps the team get focused on their tasks for the day ahead. 
  • As scrum-master I start the meeting outlining the teams short term objectives (what are we aiming for this sprint). I find this really focuses the team. 
  • Keep it short. Depending on team size (my teams range from 6-12 people usually) this should be at most 15 mins, but can be completed in under ten minutes. 
Please experiment and ask your team their preferences. If the team contribute to the processes the team undertake then they will buy into what you are trying to achieve. Empowerment is key! 


The first key to agile success - get rid of offices!

If you are new to agile there is one simple change that you NEED to make before you even read up on anything else. Sprints, retrospectives, scrum-masters can all wait - you will instantly improve your development teams productivity by changing your office to open plan with your team co-located. 

Why is co-location so important? 

  1. Communication is easier. People talking to each other to work through problems is the quickest way to resolve blocks. I see it all the time, developers talking to developers, developers talking to testers, testers talking to product management etc. I've yet to experience a major block which hasn't been resolved within a day and that is due to people simply talking to each other. 
  2. Communication is faster - who you need to speak to is right there next to you.
  3. Agile is about working as a team, and for a team to work well you need to feel like a team. Co-location helps improve team spirit, keeps people in the loop as they can hear what is going on, and all this helps to increase each team members empowerment. People being empowered in an agile team is the key to success. Remember all the key stakeholders when co-locating - developers, testers, technical writers, product management, project management... 
  4. Peer reviews are instantaneous. Regularly developers will gather round a monitor to review code, and testers sit with developers to talk through latest changes and any issues found. This speeds up development dramatically. 
This simple change can be complex for some teams - you may be an international team, need to re-shuffle other teams to get the space or may need to re-organize your full organization - but if you want an efficient team this is the place to start! 

Sunday, 19 October 2014

Eclipse - Editor hidden - Fix!

I hit a weird error today where in Eclipse I couldn't seem to open any files - the editor seemed to be minimized somehow! Even restarting eclipse didn't fix it. After a bit of playing about - I've got a solution I thought I would share.


  1. Go to Window -> New Window. This will open a second instance of Eclipse. 
  2. Notice you can now open files again. But you aren't done - you need Eclipse to remember this setting.
  3. Close the old window (the one you couldn't open files with) first.
  4. Now close the new window (the one you can open files with). This will persist your new setting (where you want  to be able to open files!). 
  5. Open Eclipse - you should be back in business. 
Hope this helps someone :-)

Monday, 13 October 2014

Promoting your own apps - AdMob in-house ad campaigns

As I've mentioned in my previous blogs, the amount an app will earn you is relative to the number of installs you have. To get installs, you need many things, from a great app to a marketing strategy.

So how can you market your own app on a budget?

One thing I have trialed this week for the first time is using AdMob's in-house ad campaigns. Essentially, you sacrifice showing someone else's ad in your app (which affects your income) in order to show ads for your own apps. It costs you nothing (except lost revenue..) but in theory it should build up more downloads for your other apps and make you more money long term.

In only 1 week I've found this to be a very effective way of launching a new app. You can build on the success of your other apps and help your new app get traction. It's great. But it's not free. You will notice a drop in income to begin with (after a week, I'm still down daily on what I'd usually get) as I'm showing a lot of my own ads. I'm basically replacing all my banner ads with my own ads. I'd estimate it costs me about $1 per install that I'm getting out of my advertising in lost revenue.

However, if my new apps start to grow and get organic installs, long term is should be a winning strategy - I'll report back with my findings. Any tips on how best to do in-house ad campaigns please add a comment to start the discussion!

Sunday, 5 October 2014

Top 5 tips for maximising app revenue

There are many ways of monetizing your apps but here are the 5 top things you can do to maximize your apps potential. Note there is one theme that runs throughout these tips - the revenue of your app is relative to the the usage of your app.

  • Display interstitial ads. This was the one change I made to my apps which instantly saw my revenue almost treble. I had previously been showing banner ads within my apps but adding interstitial ads made my revenue boom. Be careful however that you don't drive users away from your app, remember the revenue of your app is relative to the the usage of your app.

  • Establish your app early on before adding ads. I find that ads can be a turn off to users, and every install counts when you are trying to establish your app. The best thing to do is to let the app gain momentum and user base before introducing ads. After all if you have a handful of users adding ads isn't going to gain you more revenue. Remember, the revenue of your app is relative to the the usage of your app.

  • Experiment with ad placement. Do you put a banner at the top or the bottom, on every page or just sub pages, do you show an interstitial on load or on exit or during the app - it changes depending on your app. You need to test the waters with each placement (a week will suffice) and then go with the one which gives you best revenue, without affecting your user base. Remember if you turn off your users, the revenue potential decreases - the revenue of your app is relative to the the usage of your app.

  • In app purchases. This depends on your app and what service you are providing. In app purchases are great for games for adding levels or features, but it can be used in other apps too. This could be from adding other features, to simply allowing the user to remove the ads for a price. Again you need to experiment with your approach - what is the best price etc. Like everything else the more users you have the greater the number of people who may purchase something in your app.  Remember. the revenue of your app is relative to the the usage of your app.

  • Have a great app. This is the hard one - the items above are easy to add - getting the original installs is the problem. Sometimes the app doesn't even need to be great, it just needs to fill a gap or do something better. But if your app is good quality, has few bugs, and offers value to the user then you'll end up with a high number of installs (marketing I'm sure also plays a massive part here - that's a future blog...) and with more installs and users you'll get more revenue.  Remember. the revenue of your app is relative to the the usage of your app! 
These tips are my experience so far - I'd be interested to hear others experience - please add a comment and we can open up the discussion! 

Saturday, 4 October 2014

Checking income on the go

As I mentioned in my first post you can quickly get addicted to your apps and tracking their progress. To do this, you'll want to get stats on the go. There are a few apps on the play store market, and I use a combination of these to get the statistics I need.



This app gives you your days stats. There are handy indicators as to whether yesterdays stats were up or down, and whether your month is up or down on this time last month - very handy! Let's just hope you see lots of green arrows and not red ones.


AdSense Dashboard is an app I've used since I first started monetizing my apps. 

My favourite feature about this is the 2 week history - where you can work out how much you are averaging over a two week period so you can try and forecast future outcome. 

There are many other apps out there but these are the ones I use. 

So what about tracking your store ratings and downloads? That is another story altogether - I've yet to find a good tool for this. I've tried App Annie but couldn't get this to work so the search goes on...

The App Graveyard - The Depressing side of App Development

App development is great. People do it for fun, people do it for work and people do it for both. The barriers of entry to creating your own app (especially Android) are so low you can literally publish an app in a few hours and the statistics available let you track your apps progress in almost real time. The thrill of watching an app soar in terms of downloads and rank is amazing, and only rivalled by watching the money you make from an app soar. That is the justification for starting this blog - to document lessons learned and to share the joy I gain from writing apps. However, this first blog post focusses on another side of app development I've just discovered for the first time - the massive lows after the initial thrills.

My story starts in September 2012 when I published my first ever app. I started developing apps as a way to keep my technical skills up to date. I have a Masters in Computer Science and had a full time job as a Software Developer, but was transitioning to become a Software Development Manager and I knew my opportunity of writing of code would slowly decrease as the years went on. Writing apps was a fun way of developing my skills and keeping current. So I created an app and thought why not just publish it on Google Play and see what happens? I took the leap, and 2 years later that first app has had an astonishing (sarcasm) 4997 installs, of which less than a fifth still have the app installed.

Current installs by device for my first application. Whilst this is a nice linear graph, the fact there is less than 1000 current users for a free app means it will never be a good money maker.

When I started out, I never thought anyone would install my app so there was the thrill of the first time the app was installed. There was the thrill of the first day I hit 10 installs in one day, and then the thrill of my highest ever installs per day for that app of 28! Seeing this app grow at a rate I never expected led me to think - can I monetize this app? I quickly setup AdMob within my app and started to watch the result. My first month I made nothing, the next month I made an incredible 10 cents. Over it's lifetime the app has gained me £65 which is approximately $103. So why am I saying this is depressing?

The depression comes in the fact you look at your first app, and you see it grow. Quickly expectations rise, and the instant feedback every morning of your numbers of installs the previous day become important. You wake up and it's an instant low when you see you had less installs yesterday than the day before. Your earnings have gone down. You then start making more apps. Some apps take off, and others just don't. At time of writing I have published 36 different apps. The majority of them have never taken off. Three have broken 50,000 installs, the rest are all less than 10,000 installs, the majority between 0 and 100. What's worse is that you know within a few days whether the app is going to take off - if you haven broken 10 installs within the first week it's fair to say your app has been consigned to the "App Graveyard" - never to be featured in the top charts, never to be updated again as the initial feedback from the market is that the app is a waste of time.

The apps which take off are thrilling however and offer a completely different experience. These apps offer large volumes of installs per day (into the thousands for me) and if you monetise the apps you can start to get real rewards for your hobby. They key word here is hobby, as every cent or pound earned is seen as a bonus. However the earnings may get to the stage where you start to believe that this could become a business which could really take off. You may earn 30%-40% of your current full time job and think that this is an opportunity to break off on your own. You start making plans, you build more and more apps but it's difficult to get off the ground. This is the point I hit in the last few months - making plans for a business using apps.

The apps which take off have an even crueller experience which you can only experience after a period of prolonged success in an app - it's descent from a top app in the store back to the App Graveyard. You initially notice a drop in installs or earnings, and you see it as a blip. But that continues for a month or so and you start to panic. You start making new updates to your app to try and resuscitate them but it's too late. They are out the top charts and the snowball drop affect has unbelievable momentum you can't stop. My earnings dropped almost 60%  in the space of 2 months, and your dream of going solo with your app business are dashed.
This is my most successful app but you can see it is currently in decline - the nice linear graph has started to tail off to the point I'm getting more uninstalls per day than installs. The descent to the App Graveyard begins.
This is the earnings graph for that successful app - you can see that the earnings drop is even more severe than the apps total installs.

This takes me to today, where my next step is to start this blog, and re-adjust my thinking back to apps being a hobby and every cent earned being a bonus. It's a refreshing change of direction which I feel is going to change my experience back in the right direction. I'm going to create new apps, some of which will take off and some which wont and will just sit in the App Graveyard. Then it will all happen again - one app will show promise and it will move away from being a hobby again, and this cyclical experience of fun to hope to despair will just begin again!

Android Studio - How to change app icon (ic_launcher)

Changing your applications icon (ic_launcher) is a common occurrence when developing your android application. Here's quick steps on how...