Month: March 2013

How can you tell if your developer is doing a good job?

Sounds like a simple question, but the issue is surprisingly complex.

1. The developer might not develop the app you want.
    
2. The app might look right, but it might be buggy, with frequent crashes or malfunctions
    
3. The app might be incomplete – there might be important missing functionality, which only becomes obvious after the app is released
    
4. The app might work fine at first, but as the app grows in popularity, the app could slow down, until it is unusable.
    
5. You might want to engage a different developer to add a feature, but the original developer could refuse to provide source code – access for the new developer to make changes to the code
    

1. The developer might not develop the app you want.
   The easiest, in fact the only way to control this is to make sure you agree a design up front, and to demand the developer send you frequent prototypes. A prototype, as the name implies, is an incomplete version of the app, which you can install on your phone or iPad. All mobile devices support prototyping.

   There is no substitute for playing with a real version of the app, even if it is incomplete.

   If after testing the app, you discover you need to change something, refer back to the agreed design. If the developer has deviated from the agreement, they should amend their work at their expense. If your discovery means new functionality has to be added, or changed, then you need to make a new agreement, and agree a new fee, with the developer.
    

2. The app might look right, but it might be buggy, with frequent crashes or malfunctions
   Bugs and crashes during development are normal. It only becomes a problem if the problems aren’t fixed before the app is released.

   Demand all bugs are investigated and corrected before release. Dedicate time to testing the app. Sometimes bugs occur because the developer misunderstood your requirements, so you have to test everything. Do not make the final payment on the app until everything works.
    

3. The app might be incomplete – there might be important missing functionality, which only becomes obvious after the app is released
   The basic rule here is, if it is in the design, it should be in the finished app, otherwise it is outside the scope of what you agreed to pay – you need a new agreement to cover the additional effort required to add the extra feature.

   A good developer will help you identify such gaps during the design process, but sometimes gaps slip through the design process. Occasionally a gap in functionality is not identified until you start getting feedback from customers.

   The best ways of managing this issue is to pay attention to the design, to test the app prototypes, test them thoroughly, show prototypes to your friends and ask them to test them, and solicit as much feedback as you can before the app is released to the public.
    

4. The app might work fine at first, but as the app grows in popularity, the app could slow down, until it is unusable.
   This issue normally only affects apps which have to share data between different users, apps which have a server component. And it is a surprisingly grey area. If you receive an app from a developer, don’t expect it to work without modification for a billion users. Companies like Facebook and Google spend hundreds of millions of dollars every year maintaining vast data centres full of high powered computers, to provide the performance we’ve come to expect. It is unreasonable to expect similar performance for this many users, without a similar investment.

   Generally I recommend clients discuss performance during the design stage. If the app starts slowing down with a few hundred users, then I would normally count that as a bug which has to be fixed by the developer. If the app starts to slow down with a few hundred thousand users, then its time to look at investing some of the profits from the app into building a better, faster server.

   If an app is likely to grow out of its server box, cloud computing solutions like Amazon EC2 can be a good solution for scaling server capacity. EC2 offers rapid scaling of server capacity – you can add or remove servers by pushing a few buttons on a web admin form, and scale server computing power up to enormous levels, to keep app response times snappy. By the time your app outgrows a service like EC2, you should have enough money from the app to buy your own data centre.

   The cost and benefits of using a cloud computing solution for the server should be discussed in detail with your developer, during the design phase of building your app.
    

5. You might want to engage a different developer to add a feature, but the original developer could refuse to provide source code – access for the new developer to make changes to the code
   
   This is a very difficult issue in computing. A few developers try to “lock in” clients, by refusing to provide them with the code for the systems they developed. Sometimes there is a legitimate reason for refusing to provide part of the code, for example if the developer has included sensitive intellectual property which might be ripped off and copied if the sourcecode was released. But all too often refusal to supply sourcecode is a dirty trick used by the unscrupulous, to try to force you to always deal with the same developer.

   My policy on sourcecode is very simple. When the project is finished, and the last payment made, the sourcecode is yours. You paid for it. If any intellectual property issues ever arise which might prevent total sharing of code, they should be discussed up front, and agreed in writing, before the project is started.

The following are some of the technologies I use for building apps.

 
Objective C is the native language of Apple computers and iPhones. Objective C is closely related to one of the earliest programming languages, the C programming Language.

Below is a typical section of code written in Objective C:-

CCModel *model = [CCModel getModel];
[model setIsBusy:NO];
[self updateTextFields];


Objective C is fast and flexible. Apps created in Objective C are efficient and very responsive. Objective C also allows easy intermixing of Objective C code with C code or C++ code, which allows developers to take advantage of the vast library of C and C++ sourcecode available on the Internet.

 
Java is native language of Android phones.

Until Android, Java was mainly used to create desktop or server software. Large corporations often oscillate every few years between Java and Microsoft C#, depending on the preferences of the IT director.

Android changed this, by making Java sexy again. To adapt Java to a mobile phone environment, Android extensively redesigned some features of the language, especially the part of the language which controls the device screen.

Below is a typical section of code written in Android Java:-

Intent serviceIntent = new Intent();
serviceIntent.setAction("com.desirableapps.DesirableApps.StayAwakeService");
context.startService(serviceIntent);


You can mix other languages, such as C and C++ with Java, but it is more difficult and less intuitive than mixing Objective C with Java. On the positive side, the popularity of Java means there is a lot of useful Java code available from the Internet, which reduces the need to use other languages.

 
PHP is a server language – I use PHP to create server code, for saving shared data, or for harnessing more powerful server computation power, when a task would be too slow if performed on a mobile device. PHP is fast, flexible, secure, well supported, easy to write, and easy to extend with components written in other languages, such as C++ – everything you want from a server language.

Below is some typical code written in PHP:-

validateField("email");
validateField("password");
if (strlen($status)) {
   $reply = array("status" => "Missing Fields: " . $status);
   $output = json_encode($reply);
   echo $output;
   return;
}


 
MySQL is a relational database engine. Relational Databases simplify storing and retrieving data, by allowing the complexity of describing the retrieval or storage operation to be separated from actually using the data. Before the advent of relational databases like MySQL, code and data access were intertwined. By reducing complexity, relational databases dramatically improved software development efficiency, leading to the development of faster, more reliable and easier to maintain software.

Below is some SQL code used by MySQL:-

select password from Users where username = 'fred'


Why MySQL? Because its free, and does a good job. MySQL, together with SQLite, today dominate the database scene, at least outside of the corporate world. Large corporates still tend to use older databases such as Oracle or SQL Server, which offer advanced clustering capabilities (joining many database servers into one super fast database). But if you don’t want to pay for a team of database administrators, and just want something which works, then MySQL is a good choice – which is why I use it.

 
SQLite is a very lightweight relational database engine. Unlike MySQL, SQLite does not need separate software processes to run – everything can be embedded in the software which uses the database.

Below is some SQL code used by SQLite (strangely similar to the MySQL code):-

select password from Users where username = 'fred'


This makes SQLite very suitable for in-app databases – databases used by the app for storing local data, or for reference book apps, in which it makes sense for a lot of data to be stored in the app, to give a good response time when you are searching for it.

SQLite can be used as a server database, but in my opinion, in most cases, MySQL is the better choice of server database. MySQL is better at handling simultaneous connections from a lot of different users.

 
Phonegap is a cross platform development language. Essentially it turns every mobile app into a website which lives on the phone, albeit with a set of useful extensions which make a Phonegap app work far more like a normal app than a website.

Below is some code written in Phonegap:-

MyKeyboard.addListener(function() {}, restoreScroll);
RemoteNotifications.register(handleNotificationCallback);
loadDiv( 'signup/welcome.html', 'fade', function() {
      setTimeout(function() { updateRemoteToken(); }, 1000);
      setTimeout(attemptLogin, 500);
});


Phonegap can be a real cost saver – instead of having to write different versions of the same app, for different types of phone, with Phonegap you can write your app once, and have it work on any phone with minimal changes.

The disadvantage is Phonegap is very slow, compared to Objective C or Android Java, and it isn’t very good at searching or displaying large lists of data. Too often when using Phonegap for development, I find you have to compromise features of your app to fit within the limitations of the Phonegap environment.

For apps which don’t need to push the phone to its limits, such as product brochure apps, Phonegap can be an excellent choice. But for the vast majority of apps, in my experience, the disadvantages outweigh the benefits.

Hiring an app developer is like booking a cab.

If you give the cabbie clear directions, ask questions, and find out upfront what the cost of the journey will be, you generally get what you want – you arrive on time, and pay fee you agreed at the start of your journey.

If you keep changing your mind, give unclear directions, and don’t know the exact address, so you have to ask the cabby to drive up and down the street while you look for it – the cost of the journey mounts up.

If a cab offers to take you somewhere for a much lower fare than the other cabs, the question you should ask is “why”? What corners are they cutting?

If a cab looks beautiful, and impresses you with the polished chrome work of the car, the smartly pressed uniform of the driver, and the expensive leather interior, you should ask “how much is this costing me?”

Be clear. Demand clarity. Agree the cost up front.