Dealing with busy situation of finalizing development

About last 5 days were dedicated to prepare newly developed iOS app to be submitted to the App Store. During those days, unknown but high priority errors were found and prevented other issues to be solved in time. It was extremely stressful to find the causes and solutions, especially if every line of code compiled and worked just fine. As expected, the main causes were architecture related, run-time issues, which are usually considered to be more difficult than anything else.

What made me more frustrated was that, the architecture was working just fine until new feature were added for the requests that were made so late as when we were just ready to submit the product to the App Store. As we were adding new feature, processes were changed and other components were affected without our knowledge. To those who request, it’s just one more feature. However, to those who develop, it’s one more variable affecting entire system.

Also, I have realized how inexperienced I am, especially if I am under time constraining situation. If newly added feature is not working right at first, I easily lost confidence in my own design of software, and attempted to modify it to accommodate the new feature. And because this modification on the currently working design was made hastily, I often overlooked how important components were affected by recent change.

I should have more training on staying calm and keeping the confidence in finely working software design in the midst the frantic development.


Re-organizing once unclear iOS project

For about three weeks working for the company, I have been dealing with the project that has been developed by other programmers before. Looking through the lines of code, I could observe how lack of solid architecture made the project to be extremely difficult to manage and discouraging for a newly added member like me to understand the flow and make meaningful contribution for significant progress of the project.

After a week of struggling with the unclear organization of the project, I rearranged some part of the code. Though it wasn’t done for the whole project, re-structuring classes and flow of method calling based on MVC convention did bring some sense to the project and allowed me to get on the track quite earlier than how I worried it to be.

Probably, it was because iOS development is usually done by only Xcode and only one kind of SDK, and the most of recommended practices are already established firmly and shared to the public. They are clear enough for an intermediate programmer like me to apply on the project.

With this experience of re-organizing the project and being benefited by it, I am so much motivated than ever to master software architecture, design patterns, and other important practices. For a software development project to succeed, help of an architect is necessary and I wish to be the one who is truly helpful.