Don't go to Work. Get Work at your place.

If I was a FoodWorld or Coffee day employee I would try to get my work location near my place. I would love if I do not have to take these highly chaotic and carbon abundant roads everyday to go to office. Unfortunately I am not. I am a software engineer and software companies like to lease offices in a business park. And many such offices in such business park lead to a high traffic density zone.

Long time back, somehwere around 2001-2003, Google had a similar problem(Not exactly same though). They were having these same density issues - although it was more about network traffic.

So Google engineers decided we should not call 'data' to come to 'computation'. Rather we will send 'computation' to where data resides. In a way, this was like workers were created where the work was sitting. This was a paradigm shift in how softwares were built.

I feel corporates should think about a paradigm shift in the way people work. It may not be work from home, it can certainly be the closest coffee day concept.

I have been working for long in the software industry. I see no reasons, beyond some human-made constraints (feel free to read it as manager-made), that this model can not be applied to many kind of jobs.

I strongly feel that where ever work can come to humans, work should move, not humans. In my industry, this distributed work place model can certainly be implemented with ease.

Maintenance forms a major chunk of revenue for most of the ERP Application companies. I am not sure if I can give figures but both Oracle and SAP get major share of their revenue through their annual maintenance contracts. This is just maintenance while the software is in production. If I were to count the bugs which gets fixed before the software is shipped, the cost and revenue (both sides of business) caused by 'BUGS' must be significant ; enough to motivate heavy investments into automating this bug fixing.
While I agree that ERP Application softwares are not written by Computer Scientists but I can safely assume that maintenance is a significant cost/ revenue in lot of other software industries as well.

Lot of companies today do automated testing, however automated maintenance is a far off dream.

Is it possible?

The question to be answered before we even think of executing any such idea is : Does software maintenance involves more of machine intelligence(call it AI, if you wish) or human intelligence.

I have around 20 common characteristics which were common in any bug I fixed along the whole life cycle of BUG. (I call it BFLC - Bug fixing life cycle - they are really short compared to SDLC but yes, there's a cycle there). They are boring so I will spare the reader here.

Some of the important characteristics are :
1.As soon as a developer(D) sees a bug he tries to link it to any of previous similar solutions. If he thinks the problem is similar he searches for such a bug in the bug database. This is a  machine task. For instance, Topic modelling can solve this (Latent Dirichlet Allocation). Simply put, you can get links like Related Bugs.

2.D tries to categorise the bug - i.e is it a UI problem or a query problem or a code problem or simply user's wrong usage of the feature, etc. This categorisation is not a machine task but yes a machine learning problem.
Support Vector machine can be used for this.

3. D tries to make an intelligent guess about the solution and takes an approach based on that guess. (Say putting a breakpoint in probable places). This guess is a result of previous learnings stored in the D's neural network. Again this is a machine learning problem. Lot of other alternative solutions can be done as well - a generative model based on Bayesian inference.

4. Then comes actually finding the fix. This particular step is more of a HI problem than the AI. D's are needed for this step.

5. Testing the fix. It can be automated. However, all the steps mentioned here are easier said than done. In the industry not many Ds follow any automated testing.

For the step 3, if we can store learnings instead of information, (A neural network database), the accuracy of guesses should be high. As of now I have no emperical proofs.

This is a mere suggestion and readers can cast their doubts on such a thing. I am looking for people interested in working out the particular component I mentioned - I call it NNDB - Neural Network DataBase.

Regards,
Aditya Tripathi.