Planning & Development
Couple of things you should know before starting the actual Development.
You should get a schedule.
We have the specs and the design details for both the front end and the system architecture. We are good to go. But you need to know what’s going to be done and when and more importantly when the work is going to be completed by and your product is going live.
This is also to help you keep tabs on what your we are doing and how your product is coming along. Its good to keep such tabs isn’t it.
This sort of development also makes adjustments, tweaks, changes to business logic, sanity checks a lot easier. They do happen a lot and it helps to get them at the earliest.
We break the specifications in to manageable chunks typically by the modules they are designed to be. We start with the core, i.e the ones that aren’t dependent on other modules but is needed by them to exist. – typically the user module is a good place to start. The development continues for the rest of modules bottom up.
One or more such modules will be scheduled to be delivered for each milestone set at a due by date. If its a rather large module than it may span a couple of milestones. Each M.S has a list of features that’s a part of the specs document that should be working by the end of it.
At the end of each milestone you should be able to check the work completed, review and request changes if any and sign off on that milestone to proceed to the next.
As you may have realized, software development requires quite a bit of your attention. At the least a couple of meetings (5 min phone calls would do) a week. Even if you think the work requires no attention, we’d like to have you around. Partly because communication is the scaffold to a successful project and partly because one of the typical situations we see is that the application evolves as you get to play around with it as its being built. This just makes a better product. It makes even better development procedure to implement them at the earliest with out undue and expensive reworks.
Such changes in directions are pretty common and our development process is designed to accommodate them. We are agile. (zero turning radius for you and me.)
Development of a module begins with the data and structure needed to make the module functional. This involves adding db schema and some optional seed data. The business logic layer needs to be configured and coded to reflect changes to the db structure.
Usually the tricky part of module development is coming with the algorithm for and implementing the business logic. There would be some tricky problems that should be solved before the module is complete. This is where knowing you works for us.
We’ll need to consider every use case (typical and corner cases) with success and fail scenarios to get the logic right. Complex solutions are easy to come up with. The simpler and shorter the solution the better. A good programming strategy is to reduce and reuse the code.
You should be following the development on a staging server – a clone of where ever your application will run live.