Recently I was given an assignment to develop an Android application and the agreement to the price was based on the client’s budget which sometimes you get what you agreed to. What I would like to do with this posting is give young software developers guidelines on how to forge a better project and attitude towards completion for the client and the developer.
This is based on recent past experience where the client either kept adding on, told that the development was not what they expected, graphics not cut correctly by the client and finally target dates missed.
The following insights provide any developer with a check list making sure the project is ready to be designed, developed and finally released.
Payment
Payment, to judge the amount of time needed to design/develop an application you have to take into consideration, can you work on a hourly or a flat rate. Most companies will work out a flat rate when dealing with an application that they have comprised the amount of time and the cost of doing the work. Do not take this lightly, you cannot overcharge for a project otherwise you will not get the project. That is a simple method but the question is will you undercharge thinking you will get the project done quickly within an approved time period.
When you undercharge the understanding is that you will be done to make this cost effective otherwise you will be beating your head against the wall. The danger of a low-ball charge is whether the client stays on target and that bring up the target date.
Target Dates
A client always wants a project to be done yesterday for the lowest cost. Before any money is given, the software developer has to get the target dates done up front otherwise you may see the famous creeping line. The creeping line is a target date that is elusive and can possibly create a hostile environment between the client and developer. The developer has to set up what they deem is a reasonable and realistic target date schedule.
Remember targets dates are essentially the beginning of the project, the first alpha, the working beta, the code cleanup and the final release date. Keeping on track each item will make the project easier to complete. A client that waffles on viewing the first beta and the famous code cleanup after the beta is view will give you nothing but grief in the long run.
Final note, as a developer you need to understand once you agree on a completion date you better make sure you buffer time in for any type of problems that arise due to software glitches based on the language you are using or the software tools. It does happen with undocumented features naturally called BUGS. Android has it and iOS has it as well any development tool. Clients do not want to hear it nor do they care, all they want is the finished product.
Technical Specifications
Clients that do not have a solid technical specification will make the project extremely difficult and in the end could possibly kill the project.
Tech Specs provide the developer the following:
1. Screen layouts, the client has to have a clear understanding what is needed to be seen as well as the path of each screen. A simple text write up of each screen is worth more then a 2 line email which can allow the client to take advantage of adding new features that were not originally agreed on.
2. Simple text paragraphs for each screen what a user will see when a button is clicked or do they view any caption as photos are displayed.
3. Record layouts, for a client what do they want saved.
4. Target machines, where is the information stored, will it be on a cloud server ? Will it be on a SQL Server ? Will it be on a smart device ?
5. AGREEMENT
Once the developer views the technical specification and it contains every thing necessary to make it a successful project. If a client refuses to provide that then that should be a wake up call that the project can be a burden.
Graphics
One of most simplest things to forget, who provides the graphics, the developer or the client. The recommendation is to have the client provide what they want to see on the screen displays. If the client does not want to do that you need to offer them a cost involved in purchasing or developing the icons / images / etc.
Testing
The initial Alpha release allows a client to see the technical specification in work with the agreed screen layouts. If the client agrees to the path, then putting the engine together will become smoother. The Alpha will not do much except go screen to screen to demo the flow.
The initial Beta release allows a client to see what happens after a photo is taken or a button is clicked, yes things may access violate or crash but it is the beta. After the client views the beta and conduct the testing, they should provide you a detailed QA result that describes bugs or modifications that were not thought of in the original tech Specs. This is the gray area where a developer has to be firm if the client is attempting to insert new work under the guise of bug fixing.
Testing is a vital tool that any developer has to complete. This could be unit testing done by software tools or the most simple method is have someone (a friend or outside person) who has not seen the application test it out, to check the functional aspect and whether it works. A developer who does their own testing all the time will fall into the trap of doing the same tests over and over, when something comes back from the client that wasn’t done by a simple test makes the developer lose time.
Some developers tend to conduct their testing on the development machine. That is a NO-NO, try to use a target device (Windows, Mac, Smart Devices) that will be used. Application testing on a development machine you never know whether there is tools or setups that have to be conducted because the software has been loaded on this machine. Baron Software works on clean machines that the applications will be installed and tested on so that a Microsoft Office or any other sort of application will tend to install a component that is necessary for the application to work but was missed. This does show up on a naked machine.
Coding
Keep it simple. If a developer has decided to use a new concept like “Generics” or new API libraries by Facebook you may run into a learning issue. Developers may think they want to do something cool but if you are under the gun to get something done, you have to keep it simple. Nick Hodges book “Coding in Delphi” contains programming concepts in Object Pascal which can be used but the question is whether you should do so.
Smart Devices
Problems with smart devices is that if you are working with iOS someone needs to be part of the Apple Developer program, either it is the developer or the client. That has to be solved prior to starting.
With Android you have to join but it is a much simpler task in getting approved as well as inserting the APK on a web server for anyone to download to use. Apple on the other hand is very hard when it comes to putting the app on their store, you need to get the approval otherwise you will be rejected. Keep this in mind when setting up your schedule and cost.
Development Costs
This is something that any developer needs to keep in mind. If the project is a flat rate fee or one time charge the developer takes for granted that they can have it done within that time space otherwise they will work for free. All developers want to have the next killer app designed by them but in reality developers also have to pay bills for lights, food, etc. When a flat rate fee is agreed on both parties have to be happy. If the project begins to overrun the target dates the developer will inherit the costs that will make a very unhappy situation.
Always remember that just getting a project doesn’t always mean you will be happy in the end. Clients want the work done as soon as possible and once a developer agrees they are held to it by the client. All blame tends to fall on the developer in the end. If you do the necessary home work prior to the first piece of code written you will be successful.