How can a programmer develop a project within the estimated time?
Then a new project arrives to estimate, and without having much information about it, you are asked to estimate for delivery of the functional item.
How, then, to specify and say what is the time needed to develop this project, development, analysis, etc., and many times, this estimate has to be made as soon as possible? And, if the project is large, how is it possible to estimate the timing of all this?
The great reality is that: there is no way. Impossible. The estimate is simply a measure of luck, and even great programmers at Google miss these estimates.
There was once a project for feedback from Google, and the programmer said he could rewrite the code on this platform in 2-3 weeks, with less than half the lines of code existing on the platform at the time, using AngularJS. Four weeks passed, and it still wasn't finished, but it was almost over, and it delivered the project late.
If even on Google the development estimates for a project don't work, then we mere mortals, how can we correctly estimate the completion of something's development?
But, if it is a small project, like a rest API for example, this becomes a little more predictable.
Here are some tips for you, the programmer, no matter what language you use, keep in mind the following topics so that you can be able to develop and deliver your project in the estimated time (I hope so):
1. Pay attention to the data flow
This seems very elementary, but knowing what a system will receive, where it will go through and treating this information and its output, is very elementary. Having this well organized and very clear, we will have an idea of the time to develop this item.
Assuming it is a Rest API, see if you already have a data model, and all sorts of return error messages, so you don't waste time inventing during the project.
Here too, it would be the initial planning, understanding everything that really needs to be done.
2. Integration with the database
See if it will integrate with one database, or several. Have a survey of how many tables will need to be accessed, read, written, to get an idea of the flow of the items.
Include all the necessary mechanisms in this flow, and try to imagine how long it will take to develop, and include a longer time if there are connection problems, instabilities, or problems with components, such as OpenJPA, entity errors, daos, etc. This for Java, but if it is something in ASP (.net), C # or whatever, see the connection framework for the bank.
I believe that the connection with the bank is the main element that must be thought of, and after having it functional, the rest will resolve itself as a whole more quickly.
3. Integration with external services
A very common mistake is to expect that the external service is always available, whenever you want. But not quite. As it is a remote service, there may be other factors of problems, such as connection failure, failure of response time, and other more basic items such as failure of the SSL certificate, failing to connect to it (and it is not worth tolerating errors of certified, or use a connection without encryption and run the risk of it going into production and appearing in the newspapers, right!).
If you already have everything in mind that you will do with the incoming data, connection to the bank, and connection to the services, it's time to think about the next steps.
4. Presentation to the user
After having an idea of the data flow, having the flow mapped, connections and tables, and what services, connection types (SOAP, REST JSON?) And methods that will be needed for the connections, now it's time to start thinking about the time spent for presenting your application to the user, that is, the interface.
If it is a Rest API, the presentation is nothing more than requiring the parameters in the correct application / json format, in the expected format.
If it is a Web application, it is good to know if you will need to develop the front end, or measure the size of the work to adapt layouts developed by agencies that make html generally useless to adapt in layouts of some types of systems. If the agency is going to do this adaptation work, even better, it can still spend time explaining how its application works so that the other party can understand how to integrate.
We work with hybrid scenarios, server-side languages of all sorts of types and ways that the ideal was to have only one layer of API Rest for the back-side services, and a fully functional .html by itself with this API, but that's not always the way it works.
If integrating with CMS platforms, the user wants to be able to click on "edit" and be able to visually edit the content, and generally this work of integrating the html into some template is not simple. (Joomla, Drupal, Wordpress, or proprietary platforms like OpenText Portal / Vignette / WEM or Sharepoint).
5. Documentation
Very elementary in several scenarios, but necessary for the knowledge of the next teams that will act with the necessary information.
The passing of knowledge becomes a mandatory standard, and having a documentation following at least the same flow of these tips, will help someone understand how the application itself works.
Calculating time
With all this information, think more or less how long you will integrate with the database, and the services, and if possible, start a draft project or see models on the Internet of how complex these tasks can be, as well as domain over the framework used, to avoid problems in the middle of the road.
Once there is an estimate, always try to get some time for input validation tasks.
Do not take the amount that comes from the user and throw it directly in the database, treat it first. See if you accept null, whites, or if you have spaces at the beginning and end, etc. If it is telephone data, use regex or other ways to validate these numbers, ensuring data integrity so that the database is not filled with anomalies.
You need to have this time for validation, always, and you cannot spare it in any way, as this can jeopardize the quality of your project's development.
If you need to create the database, don't forget the essential normalization rules to structure the data in the best possible way. Weak, strong entities must be mapped, and tables with data maps must always be separated, and their values must, in my view, be populated by installing your application on first use.
Setting up the tasks
With all the information, and some drafts of projects carried out to perhaps understand the size of the mess, create steps, tasks, and put an amount of hours for each step.
Tasks like:
1. Develop the project structure: 4 hours.
2. Develop the bank access layer: 4 hours.
3. Survey WSDL services and perform tests via SoapUI: 8 hours.
(and etc...)
Contemplating the estimate
One of the major problems for programmers is the focus. Sometimes, it is not the fault of the programmer, but of other people who distract him by taking the focus off with other questions and daily activities. Therefore, having focus is elementary. Wear a headset, listen to some music you like, and focus on the central activity, as having everything in mind, makes everything go faster. Music with a faster pace, for some may help. Others say that without music, they can concentrate easier. See which is the best option.
Try to get through the most difficult steps within the estimated timeframe, to get more time at the end for validation steps, and organizing the code.
This would be some tips for a programmer to be able to develop a project, in my view, something small, as something punctual to complement an existing project, since large projects, should involve more people, and spend more planning time so that everything comes to pass right.
Conclusion
For small projects, these tips can help you develop what you need, managing to meet the time in the estimated time.
For large projects, practically planning and estimating take 40% of the time for the entire project. Having less time than this, can mean an increase in time not foreseen at the end, losing deadlines to the customer. Planning is essential for any project, not just systems.
No comments