I think its finally to a point where I can talk about this with some level of safety. For the past year, I have been working in New York on a top secret project for a large company. Initially, this started as a 3 month gig, but quickly turned into something much bigger as the scope of the project became clear and I was placed in the position of Lead Developer.
The application is a typical n-tier application with both a web and web service component. What made the application so difficult was the insane number of rules the system had to enforce. The company is a conglomerate, very similar in fact to RCM, and with that comes the differing ways things are done within each of the divisions or, in this case, brands. This meant that a great deal of research had to go into the system to make sure it upheld the rules for all division as well as forcing them to adhere to standardization, one of the long term goals for the company. Having to deal with this not only taught me patience but also brought an iron truth to the forefront: these processes could change at a moments notice and if we didnt design the application to change we would be in a world of hurt.
One of my greatest interests is in software development practices and study of patterns. I am often amazed at how many developers I meet, many with greater experience then I, who seem to know nothing about design and patterns. These patterns saved my skin so many times, from keeping this structured to making things more reusable and extensible. Some of the notable patterns that we used were State, Strategy, and Template Method patterns.
Perhaps the first biggest example of how these patterns helped was in their main central process. The process itself is central to the entire company. The process was initially designed to have four separate implementations, one of which was relatively simple and dealt only with the items themselves, the others had to contend with ensuring that an inventory was maintained as well. What I ended up creating was a two-tiered abstraction which housed components central to each level. After discussions with the client we came up with a set of guidelines that these process would follow; and you can guess what happened next. It was at this time the design showed its merit by making it very easy for us to make the change, though in all honesty, I was guilty of coupling to an assumption I was told was “set in stone”. The design showed its merit yet again when another portion of the project, a backend process, needed to utilize it in a different way, rather then taking time to create the module my colleague was able to do it in just under one day.
That was perhaps the biggest lesson for me: patience. I was told before I took the gig that I would be expected to train AS400 programmers how to use .NET. I initially had three students, today, a year later, I am proud to say that two of them have become excellent programmers and are fully supporting the web piece. However, the biggest challenge ended up being the mobile portion of the project.
You see, I had never done any sort of serious mobile programming before, and what little I had done was on Android. However, as the mobile piece showed signs of stalling, my client took a gamble and showed faith in me and asked me to take it over and see it through. Upon inspection of the code base it was a clear case of “you gotta rewrite this”. Basically it was totally abusing system resources, which you might get away with on a Windows app, but certainly not a mobile app. This was causing the application to randomly crash without any sort of error. This led to the company developing a second application to watchdog the app and restart it when it died.
The problem with the application was: structure, or lack thereof. I will never understand the reason why developers do not understand that a house must have a solid foundation to stand; the same is true with software. I think more often then not the answer is lack of knowledge; I have seen so many 9-5 programmers I am just sickened. I view being a developer as a lifestyle more then a job. I have to keep myself sharp or I will become a dinosaur. I know programmers who work 8hrs then go home and dont touch a computer until the next day, and yes, it does show. Thus began my crusade to rewrite the application.
What I learned here was that having successfully implemented the web application I had credit, and was able to give assurances to my client that I would keep this under control and it would not run away. After two months, I am proud to say that we have completed our first pass and that all features have been implemented. I basically ended up writing a full on mobile framework which allows for workflows, this is what guides their processes. In the end, this ended up separating things so nicely, we were even able to introduce sub workflows, all of which was based on the State machine design.
So after one year in New York what is the biggest and most important thing that I have learned: I can do it. It has given me the self confidence to know that I have the ability to be a great consultant and that I am able to take on that leadership role and guide a project technically. The thing I have had to be most careful about is: over confidence. I would be lying if I said I didnt consider moving to New York, but if you wait long enough reality sets in and being away from Michigan for so long has really made me appreciate where I come from. Much as I like the big city, right now I am still a small town guy, though Grand Rapids is hardly a small town.
The reality is, I have learned more then I can say, and I am sure not everything was good. I know I made mistakes and in the future I must work to avoid those mistakes and learn from them. I must continue to grow. And I must keep the people who keep my feet on the ground as close to me as possible.