How We work
STEP 01
Know Your Business
Can’t build a ship without knowing the ocean.
If its a niche application or an enterprise application, it helps a lot to know the native working environment of the application. i.e the domain and the work the app is going to be used in. Helps to know about other similar apps as well.
If it’s an in-house or an intranet application, we’d want to know how your work. By that I mean your typical and atypical operations and corner cases. We especially want to know the workings of a typical organisation going to use the app and the problems you currently face that may have potentially led you to this idea. The problem we want to eliminate.
This is a way to do justice to your idea. The result of this exercise makes the application that’s more tailored and make sense to that user.
STEP 01
Know Your Business
Can’t build a ship without knowing the ocean.
If its a niche application or an enterprise application, it helps a lot to know the native working environment of the application. i.e the domain and the work the app is going to be used in. Helps to know about other similar apps as well.
If it’s an in-house or an intranet application, we’d want to know how your work. By that I mean your typical and atypical operations and corner cases. We especially want to know the workings of a typical organisation going to use the app and the problems you currently face that may have potentially led you to this idea. The problem we want to eliminate.
Typical use cases and environment the app is used in is what we are after.
This is a way to do justice to your idea. The result of this exercise makes the application that’s more tailored and make sense to that user.
STEP 02
SPECIFICATIONS
The first step to creating an application is requirements and specifications.
In software development we have something as an SDD – a Software Description Document. This is what describes what needs to be built, what features to have in it, how it needs to be built etc.
STEP 02
SPECIFICATIONS
The first step to creating an application is requirements and specifications.
In software development we have something as an SDD – a Software Description Document. This is what describes what needs to be built, what features to have in it, how it needs to be built etc.
The idea is analyzed first
We identify the one thing the makes the app stand a part from its competitors if any and how we go about doing it. Most of the times it may be the ease of doing things rather than a novel way of doing things that makes a great deal of difference.
What is it supposed to do, Who is going to use it, What they are going to use it for. – this gives us the applications features, the actions and presentations it needs to do. From here we build ‘use cases’ detailing how the app flows. This may be as simple as what’s displayed on each of the screens to triggering more events on app, notifications, or getting permission or approval from another user.
The Applications personality – how it interacts with the users and how users interact with it.
this in turn User Interface and Experience guide, the tone and nature of the app and the look and feel – this is the User Interface. This lists the screens of an app or the pages of a web application, what they show, how they work with the user.
The screens and presentations are to be so created that a typical user needs zero time getting used to.
We identify the most common actions the app will be used for and plan the actions and screens to complete them in as little clicks as possible.
Now that we have who the app is supposed to serve, what is it supposed to do and how, the way it looks and the way it presents any information, we can describe the application’s specifications.
This is by far the most important step in software development.
STEP 03
Design & Architecture
We’ve finalized the specs. Great.
Now comes the technical bit. We try to decide on the brains of the app and the system architecture.
Let’s put some questions
How we build the application and what technologies to use in the app? What framework to choose?
STEP 03
Design & Architecture
We’ve finalized the specs. Great.
Now comes the technical bit. We try to decide on the brains of the app and the system architecture.
Let’s put some questions
How we build the application and what technologies to use in the app? What framework to choose?
Where and how is the application going to be hosted? Any special requirements to do so?
Typically an application is hosted on a computer on the cloud working full time running your application as a server. Its a virtual machine being either shared among other subscribers or dedicated to one user.
These virtual systems are available in all shapes and sizes to fit you. We select one depending on a typical usage of the app. Another beautiful feature of these servers is that you can add more as needed. check this out.
What data does the application need in order to do what it is expected.
Why is this necessary?
The way your application is built dictates how much you can get out of it. You don’t get see any of this backend design and architecture. But this is what you are paying for. This is the product you buy from us.
Remember
simply ‘a working application’ is no way of measuring an application. All that glitters is not gold. A poorly structured application is literally a poisoned chalice. You’d end up spending a lot of time and money fixing your product’s health.
Application design is all about having serviceable code. All applications have bugs when they are rolled out. Some more than others. Further more, throughout the application’s life cycle there are going to be feature improvements and additions.
Both of which require diving in to the code to either find and fix something or to improve an existing feature or add a new one. A well designed app lets us do that quickly and with confidence. Even by a new developer – needing little time to get to grips with how things are built. No other parts of the code would be affected by the changes – the code will be stable.
A poorly structured code will be a spaghetti code. Finding and fixing things is going to be quite a task. Add to that the code’s instability and a fix one place would break something at another.
The Data Layer is typically how the information is stored in the DB. This is a study about what database structure makes sense. Ideally we’d like to store all possible information with the highest degree of flexibility and be able to expand the data structure for future additions.
All of that with the best of data integrity and db performance.
The business logic is the brains of the application which implements the conditions, restrictions, operations, actions, presentations, etc your product needs to do. This is where bugs occur.
The strategy here again is to divide and rule. Separate the concerns, but still have them able to interact as needed and permitted. Each of such concerns are called modules.
The UI layer or the Front End is what you see as the face of the application. The specifications describe how the UI is to work in great detail. It now remains to make the app and its persona come alive with design, layout, and whole bunch of bells and whistles.
Get the web designer, Let the wire frames begin. Every thing from each of the screen layouts to icons, buttons, notifications, animations and ever so smaller details are designed.
This is where the look and feel of the app comes alive. Need to get this right. Failure of which will result again in you spending spending more time and money having redesign tweaks. For that reason this is an iterative process. We first come up with a design based on our interaction and the specs. We keep tweaking it or redesign it until you like it going on to love it and sign off the design.
The application development doesn’t begin till the design is done.
Seems we made some more progress on your idea.
We worked on the specifications to come up with a UI Design, sketched out a system architecture in detail and also sorted some technical questions.
We are good to go..
STEP 04
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.
STEP 04
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.
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.
Communication
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
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.
You should be following the development on a staging server – a clone of where ever your application will run live.
STEP 05
Software Testing
Need
Like I’ve mentioned before, all software has bugs when its first built. You don’t get to see them as the developers take the time to find and fix the bugs. Also you have be sure that the application has its logic right and working the way its intended to every time and in every case. Frankly, its rather embarrassing if your users are finding bugs and pointing them out to you.
This needs to be avoided at all costs. This is what testing is all about.
Testing does add an over head to the development cost but this is by far the highest ROI of all the development steps. Unfortunately this is the first to be skipped if budget is a concern.
STEP 05
Software Testing
Need
Like I’ve mentioned before, all software has bugs when its first built. You don’t get to see them as the developers take the time to find and fix the bugs. Also you have be sure that the application has its logic right and working the way its intended to every time and in every case. Frankly, its rather embarrassing if your users are finding bugs and pointing them out to you.
This needs to be avoided at all costs. This is what testing is all about.
Testing does add an over head to the development cost but this is by far the highest ROI of all the development steps. Unfortunately this is the first to be skipped if budget is a concern.
A stitch in time ..
As with any thing else, finding and fixing bugs as soon as they are found makes the debugging process faster and more economical. More so if the bugs were found during the development rather than when all the development is done.
This allows the original developer (the guy who knows what its for) to fix it with out some one needing to spend time and get to grips with his work.
It was that way till some one got sick of going back and fixing stuff all the time. Software testing is, for the most part, an automated process. The program is given a set of conditions and tested to see if it works, fails, or breaks.
Hey, if it an automated process why not run that before the code is written? You write your tests conditions first – setting the boundaries of what the code is to do and then develop the code to fall in to the boundaries. This is Test First Development or Behavior Driven Development.
So every time the code is changed the tests are automatically run and the code is checked to fall within the rules.
This, when properly done, allows the code to be clean, independent and of course, free of most of the bugs
Post Dev..
The code is put through few more testing cycles – UI, integration, business logic, data integrity, security etc. to get any bugs we may have missed.
And lastly manual testing. this is where each aspect of every module is gone over meticulously. Every thing from misalignment in UI to bugs in logic. This is where we catch them.
STEP 06
Verification & Quality Assurance
Staging Server
Through out the development period, we have a test server running so you can follow what’s going on and use the app as its being built. This is a platform similar to the production server the application is going to be hosted on.
All development work is updated to the staging server as its changed. The version of the application running on this represents the latest code status available.
After the development is over. We are ready to deliver the product, it falls upon you to check and verify you get what you bargained for.
Feature and specification verification is the easy part, this is the process of ticking off form and function of the app.
STEP 06
Verification & Quality Assurance
Staging Server
Through out the development period, we have a test server running so you can follow what’s going on and use the app as its being built. This is a platform similar to the production server the application is going to be hosted on.
All development work is updated to the staging server as its changed. The version of the application running on this represents the latest code status available.
After the development is over. We are ready to deliver the product, it falls upon you to check and verify you get what you bargained for.
Feature and specification verification is the easy part, this is the process of ticking off form and function of the app.
Code Review
This is where someone has to dive deep in to the code and see what’s in it. Getting in to the code can be a daunting task. Thank fully, there are specialists who offer this service explicitly. You can do this your self if you are versed with programming and the project is relatively small.
What the reviewer checks for is the quality of work. The elegancy of problem solving, code structure, adherence to coding, naming, and testing practices, documentation, data integrity, security loopholes and lapses and conformity to standards if listed in the specs.
Essentially the code needs to be easy even for a novice to understand what’s happening, follow a theme or a pattern across the entire app about how code is organised so that it’s easier to find a section of code responsible for a given action in a given module. The form and function of the code should be able to give its location and like wise reading the code should tell you what and how it does.
Once the review process is complete, you have your product.
STEP 07
Going Live
Setting Up
Your application will have some requirements to run as a server. Operating system, data base, some third party tools and apis at the minimum. The setting up process makes sure that all of these tools are compatible and work in sync with each other.
This setup is necessary if we don’t want any further complications on incompatible tools to haunt us. There’s a dedicated team to deal with setting up systems for development, staging, testing and production servers called Devops.
STEP 07
Going Live
Setting Up
Your application will have some requirements to run as a server. Operating system, data base, some third party tools and apis at the minimum. The setting up process makes sure that all of these tools are compatible and work in sync with each other.
This setup is necessary if we don’t want any further complications on incompatible tools to haunt us. There’s a dedicated team to deal with setting up systems for development, staging, testing and production servers called Devops.
Speeding Up
Throughout development, your code has been running in an ‘evaluation mode’. This is to help us identify what and where should things go wrong. Useful, but makes the code run pretty slow. – Cant have that.
You can expect to see a 2X – 3X faster production for the same traffic.
Security
There are a good number of pests the trouble web servers these days. Phishing, XSS and CSRF are the most common of them. Code and SQL injection attacks are also becoming frequent.
Port handling in the server OS also needs to be checked. Server login should always require a key file. keep it safe. If you need to, you can encrypt your db as well.
Backup
No production server with out database backup! Period. I say again. Don’t even think about going live with out a back up and restore procedure. Should something go wrong, you’d be dead in the water without a disaster recovery system.
Depending on the volume of your data and your data retention policy, your data should be backed up ideally every couple of hours in rotation.
Not just that, you should be able to go back to a database and server snap shot rather quickly.
Zero Down time
Your cloud host will promise that your application will be up 99.9% of the time. In most cases this is fine. It wouldn’t make much difference. The traffic may not be heavy to notice the down time.
To avoid such a predicament we run your application in two different servers. – that’s two different physical machines. Yet another machine set to serve the database, and a master server to direct the traffic and balance the load on each server.
The set up is tailored to the application and the business demands. The setup for example would be a bit different to cater high traffic vs high availability.
Each machine is set up to report the systems health, trigger alarms on system parameters and report logs on a daily or a weekly basis.
Hosts usually give out notifications on scheduled maintenance or required server restarts. This is something your maintenance team should keep its ears open for.
STEP 08
Product Life Cycle & Maintenance
App Ticking away nicely? Great.
When people like a product they buy, you’d want to order some more. Same with software development.
Feature Extension
Your users will suggest a whole range of new features they wish to see in the app. Some more pertinent than others. If they didn’t, then something is terribly wrong or the app in incredibly perfect. Chances are its the former.
If not for the user suggestions, it’s a great marketing and engaging strategy to show your customers that you are improving your product.
What ever reason, improving the app is always a great idea. (I said ‘improving’, not adding more and more features. It may include trimming some fat.)
We go about it exactly the same way as we did the initial development. Specs first, Milestones, and iterative development, testing, security, all on the staging server. It worked before..
The production server your clients use is untouched until the date the work is complete and signed off by you.
STEP 08
Product Life Cycle & Maintenance
App Ticking away nicely? Great.
When people like a product they buy, you’d want to order some more. Same with software development.
Feature Extension
Your users will suggest a whole range of new features they wish to see in the app. Some more pertinent than others. If they didn’t, then something is terribly wrong or the app in incredibly perfect. Chances are its the former.
If not for the user suggestions, it’s a great marketing and engaging strategy to show your customers that you are improving your product.
What ever reason, improving the app is always a great idea. (I said ‘improving’, not adding more and more features. It may include trimming some fat.)
We go about it exactly the same way as we did the initial development. Specs first, Milestones, and iterative development, testing, security, all on the staging server. It worked before..
The production server your clients use is untouched until the date the work is complete and signed off by you.
Maintenance
Scheduled maintenance is required for every server. Clean up trash, update the dependent tools, O.S if needed, check the backups etc.
Over time you will have gathered more and more users and generated a lot of traffic on the site. You may or may not notice the drop in server performance which is its way of asking for more hands. Remember the weekly server health reports we get, they tell us if such a situation is imminent.
This is when you scale up your servers. There are lots of ways of doing this based your business, geography, volume and type of application.