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)
