C#, VB.Net, XML and mass consumption of coffee.

Many many years ago when I landed my first coding job, I was amazed at how different working in a software development shop was different from what I had pictured in my mind.  At that time, I did not even graduated yet, I was in need of money and it seemed like a great opportunity so I took the job.  While driving to my new place of employment for the first time, I was running some scenarios in my head, trying to remember some tested and true algorithms, thinking of whole bunch of technical things that might help me impress my then new boss; what came as a complete surprise to me was the fact that I had no idea what the work was about.

After couple of weeks, I began to realize that many things that were part of my job were not covered in school at all.  I can’t really blame school for that, after all they were trying to give me as much information as they could about technical aspects – languages, algorithms and all that jazz, I myself had failed to learn the truth about real time work of a coder, and I did have opportunities to do so.  Later on when I became a manager and was interviewing people for coding positions, I realized that I was not unique in this lack of knowledge.  Most of the recent graduates were in the same boat that I was in years ago. Read more…

One of the things that drove me absolutely nuts when our department was in the same building as the rest of the company was the fact that nobody could quite understand what we were doing. Quite often we would get a data entry person storm into our office and demand that we fix their Outlook or install Unix on their machine (it turned out that he needed Putty, not a true Unix install). Usually these conversation started with “You guys are not doing anything, right?”. So many times I was trying to explain to everyone that it just does not work like this. We are not just sitting here pressing keys at random most of the time. Best and by far most common argument to support their need for our involvement that I heard was something like this: “It is not going to take long, could you just do this for me right now”. One of our duties was writing a variety of Excel macros for people(I should probably post some tutorials on this subject). After all when dealing with massive amounts of data, it is faster to write a macro then do something by hand. We did not mind doing macros at all, what we did not like is when the person was sitting on the project for weeks and then decided to approach us at the last minute. Client expects the project to be completed at 5 PM, so the analyst strolls into our office at 4:45. Never mind that it takes him about 3 hours to explain to us what on earth does he want macro to do. Never mind that it takes me couple of hours to code the macro in some cases(trust me, there were some huge macros). It had to be done and that is it.

Number of times we attempted to find a solution to this annoyances. For instance we created a little internal web site that would, in theory, help users solve many issues like setting their “Away” message on Outlook and server connection through Putty and such. I did this web site in about 3 days when my computer was send away for repair and I was working on an antiquated piece of hardware we found berried in a storage. Was this web site ever used? No, it was not. Office people would still storm into our office saying that they did not read the instructions as they would not understand it anyway.

The worst part of these interruptions was that it would completely break my line of thought. So you are working away on a complex algorithm with close to no documentation on the objects that have to interact together available. You are concentrated on the task 100 percent, not even noticing that that cup of coffee is now cold, and then all of a sudden you have someone storms in and demanding that you fix their radio right away, or else.

The idea that you just had about this nice piece optimized piece you are about to write is gone now. I must admit that couple of times I flipped. It ended up with me yelling at a poor data entry person, calling them names, questioning their intelligence and so on. After I usually worked from home for a day, but at home there was a urgent need for a game of soccer or emergency epic hide-and-seek battle with my kids. I do enjoy those, but working from home was not a big option from the point of getting any work done.

Few years have passed and then our lease was up. I knew that was the moment when inaction would cost me dearly; I begged and pleaded with my boss to get us a separate office. Likely he agreed with me, and for the last two years we are in a different building, about 40 minute drive away from the main office. At first, main office was really concerned with who would be helping them out with daily tasks, but after about a month they learned to do it themselves. That little web site was finally used on the regular basis. We were not bothered with those requests and could finally spent close to a hundred percent of our time on coding and related things. Our productivity sky rocketed, we were producing better code more quickly and everyone was much happier.

The point is – developers can’t be disturbed. It is a process where ideas and thoughts need to be followed and processed carefully to produce what could be considered good code. You must create a barrier between your coders and outside distraction to produce quality software, and after all it is the purpose of any development team.

Bad code we all do it.

Well, I had written my share of bad code. Couple of weeks ago I had to fix up a class that was written about 4 years ago. For a while I could not believe I wrote this, but the comments on top clearly identified me as a suspect. The thing is we all write bad code sometimes. If you never wrote any bad code, please raise the hand with which you did not do it.

So, going back to the story – I was looking at it and my first impulse was to try to hide it far away so nobody would ever have to look at it. My second impulse was to rewrite it. I figured, it would probably take me about 5 hours to redo this. I did not do any of it. Instead I brewed a fresh pot of coffee, put my pride far away, printed out copies of it for all developers in the office and decided to play a game. Read more…

Rosetta Studio is about 5 years old.  It was started as a little side project, but grew into a popular app within our niche.  Right now we are quite comfortable with our release schedule, we take time before actually releasing to analyze and test the software, as a result there are fewer bugs and overall customers are happy.  But it was not always this way.

When I joined RS team, well, there was no team.  There was Matt, the guy who came up with the concept and there was me.  Rosetta then was in v 1.2, so we did not have many features implemented, basically the app was so vanilla, we only had 2 clients.  We had lots of ideas, and very little time and patience to maintain some kind of development system that would help is stay on course.  On top of coding, we had to do sales and support plus we were expected to help everyone else with their computer related problems (like fixing Outlook and writing Excel macros).  All this left very little time for development, and we had potential clients breathing down our necks twisting our arms to get the features they wanted implemented soon.

We were working in a fire brigade mode, there were fires, and we had to put them out fast.  There was very little time to think about writing optimized and efficient code.  As long as it worked, it was good enough.  This might appear as a good model for someone with a new app, features are added quickly, we had releases quarterly, our client base grew and soon we realized that we don’t need to put out fires.  We still have a list of suggestions (which actually more like demands then suggestions) and we are working on those, but now there is no rush to get it done, so we are doing it properly now.  Matt is gone now, I lead development team, and we got enough coders to maintain a good pace and write quality code.  But the stuff that was written in the past is not going away.

Right now we are rewriting Rosetta from scratch.  We need to adapt to the new framework, plus Office 2007 and localization and let me tell you, it’s a lot of work.  To address the issues of the old code, and believe me, I was thinking about it for quite some time I came up with this weekly code reviews.  Now every week one of us takes a function from those old classes and rewrite it in the most efficient way the developer can imagine.  Then, the developer has to present his work to everyone, explain briefly what the class and the function is all about, what and why was changed as well as measurable benefits of the change.  I thought that first of all we will slowly start changing the code, which when done properly is a good thing, some of us get exposure to classes that we never worked with before and we would share some of or knowledge.  To start it, I decided to go first.

Picked up a function, shaved some time on execution, dropped a loop, did some smaller things.  Just to make sure everyone is paying attention put some goofy things with appending a space to a string and then trimming the end of it.  Everyone caught it right away; I guess the guys are responding to this new idea.  We’ll see how will it progress, but basically I would recommend this to everyone running a small development team as a good exercise and learning experience.