Overview
Before almost a year my friend developing mobile applications asked me to help him with importing some data into Azure DocumentDb because he has never worked with it. When I asked him why he was doing it instead of somebody who was responsible for it, he replied that there was nobody else. So we imported data, wrote a manual. And at this point the fun begun.
A Story
A company A wanted a mobile game (with some backed stuff). Because of internal rules, one company made analysis and another company developed the product. So firm B wrote a business analysis. Company C did the backend part and company D did mobile apps. Because there was another company’s A politics, company E was maintaining many backend apps for company A (and it happened that even the company E was taking money for it they were not able to update db).
The game had to be developed for all platforms, even not so common Windows Phone, so external developer F made this version for C. A department of company A (G) was controlling sign process for app stores and required manuals for mobile apps. Which is correct. IOS and Android was published without problems, WP not.
Because of “Works on my machine”, there was a problem with WP app. So why not to go to the company and solve the problem on site? The problem was the developer F. He didn’t want to go. Don’t ask me why, I don’t know. So they asked me if I could try to make it working. I have never worked with Unity and I wrote just two simple WP apps for fun – not so many experiences. It took me a few hours to inspect the code and make it working successfully (e.g., Unity needs full paths that is almost not possible to change and the better solution is to create same folder structure as on original PC where the project created). So I compiled it and sent it to store under my account. Good, it was working. Next I wrote a tutorial and went to G department. We run the app build and it failed. There were missing libraries. After inspection we found the problem. The app was targeted for Visual Studio 2015, but the firm run officially on Visual Studio 2013. But there was no requirement for that. So we changed versions of referenced libs to older versions, built it, signed it and deployed it. Finally with success, but it took us time that could be saved.

A Story Continues
After more than half a year I was asked to update the app backend. Ok. Give me specification and code. They sent me the code in a zip file. There was no source control. That was all they had. The app was not able to build because of missing configuration file that was excluded from the source versioning system (it was easy to fix, but it should be mentioned somewhere – there were custom keys for app configuration). When I opened the project, there was no single test. But a lot of TODO comments about what is missing and should be done. No code comment. Next it had a strange code structure – mixture of models and business logic together. Entities from DocumentDb were sent out of the API exposing internal _id and other properties that should not be published to API consumer. Next, there was no official staging environment, simply nothing. …
Conclusion
My question is how is this possible in these days (and that is not all):
- No backend code documentation for the company A (G).
- No official code versioning in company’s A (G) repository.
- No staging environment.
- No tests – how to update the app if we do not know if the change did not corrupt current functionality.
- It seems there was no company’s A (G) code review process because of many TODOs and design mistakes.
- Specification does not contain such non-functional requirements.
- Company that is paid for controlling particular apps using particular technology does not manage this technology.
- This quite simple app, so what about some bigger and more complex project?
- What about lost money?
- …
So I hope that this is not a common model how a software for companies is done. Especially in these days with hundreds of tutorials, best practices, certifications and audits.