When everyone agrees

Don’t you find it odd when everyone agrees, or it feels like at times?  Then there is an eerie silence… Even odder in remote WebEx/Skype type meetings.  I have been working with off-shore development over a year now and have mixed feelings during this interaction.  Most of the time, it feels like we all agree but tangible outcomes are not happening. 

First of all, I am not sure if the rules of the game are set the same both for on-shore (US-based) or off-shore (outside of US).  Definitely there are differences in our training background and our craftsmanship and values. As a software sr. developer, jr. architect who is trained in the US and actively practicing over 13 years, I value good software craftsmanship, applications which are tested, designed and developed according to some best practices that maintainable and scalable.  This is really what I strive for and encourage & mentor others do so, including soon to be my past my off-shore team as well.  However the road traveled was rocky, and ran into a few obstacles. 

So what happened?  Good question. My off-shore team has an engraved way of doing things and it was hard for them to learn test-driven development, understanding tier-based architecture, not creating large “GOD” classes, writing explicit, modular functions rather than monolithic top-to-bottom “Know-it-all, Do-it-all” methods, avoiding code duplication  Quite a few are documented by Jeff Atwood back in 2006 (Coding Horror) and many others in the past.  Unfortunately my team was mostly VB6 developers with a few exceptions.  How do I know?  Because I was one.  I am not saying that being a VB6 developer is bad, but times have changed and maybe you should too.  And please stop using Hungarian notation for crying out loud… #pet_peeve

Writing Legacy Code and continuing to do so

Yet with the releases of .NET 2.0, 3.5, and now 4.0, and influences of Open Source (especially for the web), and changing face of software development (Agile development, Scrum, TDD, BDD, etc), it was time for me to change then back in 2005 change others.  Can’t write code the way it was written 10 years ago (Waterfall, monolithic, client/server etc.)  Somehow my off-shore team haven’t received this message because no one probably delivered.  They were content delivering applications with looks and feels of the late 90’s and early 2000’s.  Eyebrows raised and points made over WebEx, but not much happened.  I bet they did not see my eyebrows though :)

According to Michael Feather’s “Working Effectively with Legacy Code”, legacy code is code that has no tests.  I am not going to discuss the details of his book and why writing "zero” tests is not good, but the point is, if you want to write good, scalable, readable, and usable applications, you better have tests around your code and features.  This is one of the first things I tried to set guidelines around with the off-shore team with partial mixed results.  Yes, they are writing tests, but most of them are fulfilling a requirement rather than testing their code or logic, or help refactor their code. Ugh.

Usage and throwing exceptions created another interesting exchange with the off-shore.  In .NET, exceptions should be used judiciously, and as the name implies, they should be an “exception”, like an “accident”, you didn’t see it coming – not to be used in regular workflow, such as enters a wrong password(?) In once incident, I seemed to have convinced the developer this being the case, but come next day, you find the same type of code with a different signature.  A totally a “Gaaa!” moment! Yikes.. Again there was really not much re-enforcement,  application works, users are happy*. Next feature please..

N-Tiered Architecture and Separation of Concerns

Even though you may have created a multi project solution, it does not guarantee that your project is tiered and respects the notion of separation of concerns.  When I joined, I introduced the Model-View-Controller architecture for the ASP.NET development.  At first I had a different off-shore team and we also had struggles especially with less than stellar user experience requirements.  You have to understand how difficult it could be if you try to write a windows application on a web browser.  And my team is set to achieve just that with the support product owners. 

Another sticking point with my off-shore was overuse of stored procedures.  Okay there are two camps out there on this, but come on, it is 2010, and we have OR/M tools including Linq and Entity Framework, data transfer objects, business classes, etc.  And how do you test it, especially edge conditions? Below is a part of one of those sprocs.

   -- ...
   My_DateTime <=DATEADD(minute, 59, @MyDatetime))
   -- ...

Above, what happens the programmer uses “<” instead.  How do you catch that? What does “59” mean? Hint: minutes.  Let me tell you long stored procedures with convoluted business logic is certainly not my cup of tea.  With the existing legacy database we had a few thousand stored procedures written over the lifetime of applications.  God knows which ones are in use and which are deprecated, but can you imagine the amount of effort to review those and clean them up? I digress.

Anyway, it has been a quite an interesting journey and experience.  I have some good takeaways, and developed very good friendships over WebEx and Skype.  But I do miss the opportunity of having face time, have a chat with the developer/peer, preferably over a beer on some design pattern or an intense code review.  Thus turned in my resignation, and now off to new ventures.  Let us not forget to have discussions and does not mean it is all good when everyone agrees.  Because, really, they don’t!

Happy Coding! (just be sure to leave “code smells” in rear-view mirror)

Working with Offshore

The increased efficiency of the online communications tools, offshore software development has become more prominent in the IT industry. Currently I am working with a bright off-shore development team located eight time zones away. There are some challenges, but overall things are moving well. In this blog, I would like to share my experiences and give a few tips, if I may.

Communication

Obviously not everyone speaks, writes and reads English as their first language. English is also my second language, but living in the States for over fifteen years, I seem to do well and even blog about it. Specifically with software development, getting one's point across is very essential when the team is not co-located. We use a few online, instant messaging and audio/video programs. Earlier we tried ooVoo, however the off-shore team found that it was CPU intensive (with all the ads and everything on the side which I am not too surprised), and they suggested we use Skype. So we switched. It works pretty well and adds to our daily email exchanges. Definitely pick an instant online communication tool which all the team uses

Within the team, our direct point of contact speaks the best English as expected, yet others are good in writing. There was one time that I called one of the developers and could not understand what he was saying, and he probably did not understand what I was saying either because he requested that I speak slowly. And yes, I could speak quite fast at times. Then I quickly switched to instant messaging. This allowed my offshore developer to think more over the text he reads, then respond. I don't plan on calling him directly anymore. Although a conversation is good thing, but it feels odd when the other party is not sure what is being said. Video definitely helps with sending the gestures and such. But in general it is good to keep things in writing.

Get to know your team

Haven't got the chance to meet the team in person, but initially I mentioned that I was going to visit their country and asked and requested for certain information. They were quite excited and eager to share the info and their culture. I inquired from one of the developers about his beer tastes and whether he drank it or not. Again myself being from overseas, which is not too far off from this location, exchanged a few other stories and got a little more personal. I think this really helps in creating a more friendly and understanding atmosphere.

Don't be a dictator

One of the lessons, no matter how smart you are (or think you are), hopefully learned is to cultivate a shared development environment. Recently the off-shore team went ahead without checking with us and completed major refactoring. That caught me off-guard, but there is a lesson in that. First, the project needed refactoring and I was reluctant to do that right away due to another pending major integration (back-end) process. But that was all right. We regrouped and just this morning we had a teleconference call and discussed our refactoring process where I think everyone got on the same page. I did answer a few follow-up clarification questions but everyone is on the same page.

Let them have time to ramp up and study

In this project we are using ASP.NET MVC framework. Early in the project, one of the developers decided to take the M (Model) from MVC of the web project into an outside class library project. After checking and figuring out the reasoning, we found out that it was not such a good idea since ASP.NET MVC dictates convention over configuration. Yet the idea is to let the team find out and try to improve the code through refactoring and remodeling. My advice to team was, okay, there is another way of doing, but prove that why that way is better and if it makes the most sense.

Respect gets respect
This goes without saying, but it is better to state it anyway. Just because you are supervising, there is no point in being arrogant or bullish when discussing issues with the team. Everyone has opinion and when time comes, it is best to discuss. Try to understand where the team is coming from and give them respect for their idea and creativity. There is always more than one of peeling the cat ;-)

Try to stay ahead of them

Okay, this is my current challenge right now. We added two additional developers and it is getting harder for me to stay ahead, but I will keep reviewing the code base and provide feedback as it fits. I also have the other integration project which is ramping up as well. Anyway that is what I got to do. But the point is, it is important to stay ahead of them and give them direction and try to anticipate the changes in business and requirements. The one thing that is certain is things are going to change. Be responsive and reactive to changes, hopefully proactive more.

There will be many more tasks for us to do in this project. We have an agressive timeline, but using agile methodologies, specifically Scrum really fitst the model. We modified the process a little to meet our needs but it is going through. Our business analysts are creating documentation everyday which the development team is consuming. The TDD approach is really getting up there. Just today we got notification that our initial code coverage setups and implementation are taking place. These are great signs of progress and will hopefully allow us to deliver this product on time and within budget. I am stoked to work with these bright guys and I am glad to mentor and learn from them as project moves forward. But understanding each others' culture, either onshore or offshore and working on the communication skills are essential to what we do which is creating functioning software applications for healthcare business.

References:

10 secrets of successful offshore developmen parts 1 & 2

25 Rock Solid Tips to Supervise Offshore Development