So as I lay here in a hotel in Queens, New York I have had a chance to reflect a little on the experience I have gained over the last few months as I worked for the client out on Long Island. There were many high points and a few low points, mistakes made and successes gained. All in all, I really couldn’t have asked for things to have gone better. I wanted to take some time and share with you some of the the things I learned and/or experienced.
1) The virtues of planning
As a programmer we often hear the stories about staying out late or working long hours to finish a project. I can recall many people in college pulling all nighters to finish projects and the constant stream of rumors from the West Coast that programmers out there often sleep at the office. I have never been a fan of such a thing and usually feel that when you find yourself in such a situation it is most often because you did not plan accordingly.
With this project, I made every attempt to plan. I planned what I was going to do, I planned what I was going to concentrate and think about for the future. I thought about what I would train my colleagues on for a given day. And in the end it really paid off, I worked very little hours and accomplished a great deal. The application that was built was built in accordance with known practices. In fact, a colleague was sent to a Microsoft technology seminar where practices for developing an application was discussed. Upon his return he shared with us what we learned, and essentially described the application’s architecture as I had intended it. This was all thanks to proper planning as well as the invaluable lessons I learned from working with a host of people at RCM.
2) Communication is vital and can be redundant
I have always had a hard time remembering things, so I write stuff down. But when I write stuff down I become too detailed and I miss stuff being said as I am writing stuff down. Thus I am a person who likes to try to understand small detailed chunks and maintain a high level conceptual understanding of what I am doing. I am also not someone who can understand everything via reading, I am very kinetic learner. Thus sometimes I had to ask questions repeatedly to make sure I understood things, especially when it came to the sometimes complex business rules of my client.
To help with this I created a great working relationship with all of the members of the team by being myself. By the end, I felt like one of the members in the company, not a consultant and I was able to speak candidly around them, always maintaining who was in charge. There were times I had to take charge of a situation and explain what can and cannot be done on the fly. I remember once that I had to explain that adding values to a table was great but unless the application knew what the value mean’t you could not add functionality this way, at least with the architecture that was put into place.
I owe this great level of communication to the high satisfaction the client has with what was produced and what they learned from this experience. At the start of the project a couple people knew some .NET others had only ever done AS400 programming. By the end today, they were able to speak about various abstract concepts that they had come across in their own research or things that I had spoke about during training. And they were able to understand why I had made the decisions that I had and how to help each other continue with the design concepts already in place.
3) Dont accept tools and frameworks blindly
If you read and follow this blog you know that we decided to use the Coolite UI framework for this project. Coolite is an set of controls built around the ExtJS framework that is designed to help developers quickly create a rich and visually appealing websites quickly. With the lack of a designer on the team this framework was very appealing and was chosen as the backbone for the application; this was all before I arrived on the scene.
Initially, people were ready to go with MVC and Linq2Sql so we started down that path. But I quickly noticed that this application was going to be complicated and require an advanced architecture to support the requirements. I have no doubt that such an architecture is possible in MVC and I would really loved to have done this application in MVC. However, given that I have far more experience with Webforms and Coolite worked better with the event model offered by Webforms I convinced the client switch to Webforms. While I also tried to convince them to move away from Linq2Sql in favor of the the Kinetic Framework, which we have used at EIS for numerous large web projects.
In the end, because the application was designed so modularly it really could support a change in ORM without a major change, but the reason that was given to me was since the client wanted to use SQL stored procedures for the operations Linq2Sql seemed the best choice to them, so I lost that argument. However, by the end I spoke with the client again about this decision, and he agreed that given the chance he would have revised his decisions and decided to use Linq in place of the stored procedures.
All in all the experience was exceptionally positive for both myself and the client. The application that was created was visually appealing and rich in functionality, and all through the QA sessions very few bugs were found and no critical bugs. Of course, as the application moves to the official QA team I expect that problems will be found but with the excellent communication regarding project requirements I feel that these problems will not be serious. In addition, I was able to impress upon those I was training the value of not just .NET and its languages, but also the value and ability to think abstractly enough to work in a object oriented environment. I look forward to my return in two weeks to assist the client with a second .NET project while the approval for phase two of the current project is decided.