Static v/s Dynamic and the Corporate Developer

After reading this *very good* blog post by Sidu, I had mixed reactions. The post is no doubt good. If you haven’t read it, go ahead and hop over. I won’t summarize it here and take away from the effect of reading it first hand. I am off to go on a tangent here .

Static, dynamic, C#, VB.Net, Ruby, .Net, and heck even Java. That’s a lot of hammers to “nail” the problem. The business problem we are trying to solve, that is. I agree with Sidu that getting the job done is paramount. My question is, if you are a corporate developer, what choices or freedom do you have selecting the right hammer? The business stake holders do not care what hammer sends the nail in, as long as it is not the proverbial last-nail-in-the-coffin.

Say, you work for a great company, joined at an early stage in your career, and suddenly you realize Ruby, or heck C# is the “language that talks to you” like Scott says in this episode of Hanselminutes on F#. What are your choices? You cannot start coding in C# (not that it really matters with the framework) or whip out an application in Ruby or use the Rails framework.

Do you look for a new job? Who is going to hire a VB developer who now thinks Ruby is the call? Recruiters won’t even respond to you.

My question is, how do you go about, say, implementing an application in Ruby on Rails in a non-ruby shop? How do you convince the stakeholders that this shiny new hammer is perfect for the nail? Take my former employer, Blackbaud, for example. Blackbaud is a VB.Net shop. A bunch of extremely sharp guys run the product development department.

<ad>If you are looking for a new job check them out. Its is a *GREAT* company, near the beach in Charleston, SC and they are alyways looking for good people</ad>

Working at Blackbaud is great. But then, when you wake up with an itch for Ruby or C#, how do you convince the powers that be to switch. Does that even make sense to ask to switch? Probably not. So, in that situation what are your options? You don’t just walk out on a good career. Especially not if you have a family. You don’t just uproot everything just to scratch your itch. You just pick up the tried and tested hammer and go about banging the nails.

One solution is probably to work at a consulting company, say like Thought Works. This company looks like the “place to be for all things cool” if you read their blog. But, can you really pick up any new shining hammer to nail the problem? I don’t know. Having worked ay Infosys, I can say it is possible. The opportunities exist, unlike in a typical corporate setup. But I am not sure if you can just keep jumping on the latest bandwagon and roll along without gathering moss.

The true solution is to work on your core competencies and hone them. Languages come and languages go. Bandwagons are going to have their ride. But if you work on understanding the principles of business and concentrate on solving the problem, you will get far. Not all problems have a solution in a console app. Heck, if you can make the problem disappear, then I would say, you solved it. No problem, no solution needed. Follow that, and you will do good.

Now that we are way out on a tangent, to parapharase Sidu, *GET THE JOB DONE* and be careful with that hammer. Don’t drop it on your toes.

Advertisements

About Ramesh Sringeri

Yet another chaos monkey. View all posts by Ramesh Sringeri

8 responses to “Static v/s Dynamic and the Corporate Developer

  • Sidu

    I couldn’t agree more – life is full of trade-offs. If you can’t choose a hammer but everything else about the job is good, then that’s a tough call. Even at ThoughtWorks it isn’t always funky stuff – we get our share of CRUD Java apps.

    I think it is also very important to understand the technologies available so that you can decide what is best to solve a particular business problem – a sound understanding of the domain won’t suffice. Every developer should be familiar with OO and functional programming techniques. These principles are not limited to any one language or stack, and they shape the way you write your code. In fact, that is why Business Analysts are permanent members of any TW team. They don’t just write a spec and vanish, but are there throughout the project, working at the same table as the developers and testers. We usually have around one analyst for two pairs of developers, so they are always accessible. This reduces the amount of domain knowledge that devs have to imbibe in order to be productive, and frees up their time to research new stuff. Of course, this is biased toward consulting projects which last for not more than a couple of years, not product development where in depth knowledge of the vertical is a huge productivity booster.

    The language and platform is just one part of the equation, however. As my colleague Vivek Prahlad puts it, the trick is in creating the fun. There’s always funky stuff that you can extract out of even the most mundane application. Here’s an example – you know that data binding in .Net is done using strings. Ridiculous notion, but there it is. For us, this means that we cannot use refactoring tools like ReSharper to manipulate code – quite a set back given how much we refactor. So this team in Bangalore which was on a .Net project came up with a nifty little framework which allowed them to work with actual methods, while exposing strings to the databinding api. It’s challenging, it’s fun and it boosts productivity dramatically. And thats just one of the neat things they’ve done there. Among other things, they’ve also rebuilt XStream.Net from ground up removing a whole lot of bugs and dramatically improving code quality in the process. See what I mean?

  • Ramesh Sringeri

    Sidu, well said. Yes, understanding various technologies is very important. You said it much better than I tried to. If you are not aware of the different kinds of hammers available, you will always try to bang the problem the same way. I agree that just domain knowledge is not enough to hash out a solution, but it is an important part of developing the solution. Like I said, business stake holders don’t care about the methods used as long as the problem is suitably addressed. But, understanding the technical aspects are an important part of the solution development, lest you are locked in and have to solve the problem again.

    Good to note that you guys strive to elicit fun and make the most mundane tasks interesting. That sure sounds creative and exciting. Red-Green-Refactor is a great way to put together a solid system. But sometimes I wonder how many cycles or projects does one go through before you start writing code that does not need too many refactorings. The earlier refactoring experience should count toward something. Or is it like drawing a picture where you draw out the rough sketch and then refine it? Being a drawing enthusiast myself, I tend to work that way.

    The bottom line is, one should strive to be a better developer like the latest meme going around and as outlined in this episode of Hanselminutes. I would say one should strive to be a better solution developer.

    Thanks for your good insights.

  • Susan Potter

    Here are the things business stakeholders care about:

    1. Time to delivery: depending on the type of web application or web services platform your are trying to create, you might be able to make this argument for the Ruby/Rails stack. (I would also add in RSpec to the stack as I can personally no longer use xUnit frameworks after using RSpec unless forced to – i.e. if there isn’t anything like it yet for that language/environment).

    2. Qualify of product: again I think Ruby as a dynamic language in many ways forces good developers to be even better about speccing/testing, whereas in statically typed languages especially like Java make some developers think the bytecompiler will catch most things for me. That is simply not true and creates a false sense of security for developers. In Ruby you can’t lie to yourself about these things. It is a dynamically typed language, so you are forced to fess up and the good developers (i.e. non-PHP-hackerish types who actually know what OO means) will get more TDD/BDD (which is exactly what happened to me). How do you translate this to business stakeholders to mean better quality. Well think of it this way…any time a developer makes a change to the application or platform, they can verify if it has broken any tests/specs in a matter of seconds. The larger the test/spec suite is and the greater code coverage it has the more likely it is that it will discover new defects you have introduced than when the suite is smaller (and infinitely better than a non-existent test/spec suite).

    3. Smaller iterative steps possible: if there is one thing I have noticed w.r.t. to my business stakeholders when moving from heavyweight Java/J2EE/JEE/JUnit+jMock to Ruby/Rails/RSpec is that I was able to deliver pieces of functionality back to them much quicker than I was otherwise able to. Not only is the number of production lines of code generally less (though my spec lines of code are usually more because I really enjoy speccing now) in a Ruby/Rails stack, but he hassle of deployment of a Rails/Mongrel/(LigHTTPd|Nginx|Apache) stack is usually much less pain than a JEE/(JBoss|WebLogic|WebSphere) stack in addition.

  • Susan Potter

    Here are the things business stakeholders care about:

    1. Time to delivery: depending on the type of web application or web services platform your are trying to create, you might be able to make this argument for the Ruby/Rails stack. (I would also add in RSpec to the stack as I can personally no longer use xUnit frameworks after using RSpec unless forced to – i.e. if there isn’t anything like it yet for that language/environment).

    2. Qualify of product: again I think Ruby as a dynamic language in many ways forces good developers to be even better about speccing/testing, whereas in statically typed languages especially like Java make some developers think the bytecompiler will catch most things for me. That is simply not true and creates a false sense of security for developers. In Ruby you can’t lie to yourself about these things. It is a dynamically typed language, so you are forced to fess up and the good developers (i.e. non-PHP-hackerish types who actually know what OO means) will get more TDD/BDD (which is exactly what happened to me). How do you translate this to business stakeholders to mean better quality. Well think of it this way…any time a developer makes a change to the application or platform, they can verify if it has broken any tests/specs in a matter of seconds. The larger the test/spec suite is and the greater code coverage it has the more likely it is that it will discover new defects you have introduced than when the suite is smaller (and infinitely better than a non-existent test/spec suite).

    3. Smaller iterative steps possible: if there is one thing I have noticed w.r.t. to my business stakeholders when moving from heavyweight Java/J2EE/JEE/JUnit+jMock to Ruby/Rails/RSpec is that I was able to deliver pieces of functionality back to them much quicker than I was otherwise able to. Not only is the number of production lines of code generally less (though my spec lines of code are usually more because I really enjoy speccing now) in a Ruby/Rails stack, but he hassle of deployment of a Rails/Mongrel/(LigHTTPd|Nginx|Apache) stack is usually much less pain than a JEE/(JBoss|WebLogic|WebSphere) stack in addition.

  • Susan Potter

    Sorry for the repeat comment. Firefox became temporarily possessed by the devil there.

  • Ramesh Sringeri

    @Susan, those are some very good points. I would sau, anyone with a stake in the system, should care about, time to delivery and quality of the product. My point is, as a corporate developer, if you discover a new paradigm of new way of doing things which lends to better software, how do you go about instituting the change. I think I was too broad when I said business stake holders do not care about the tools used. Like you said, Ruby and Rails have these idioms that when followed correctly help building solid systems. Like DHH said, Rails gives you test classes for items it creates so someone who is just starting out goes, oh, maybe I should be writing tests for everything and pretty soon they are writing better code, code that can be tested better because Rails sort of leads them dowm the right pathway.

  • Ramesh Sringeri

    @Susan, those are some very good points. I would sau, anyone with a stake in the system, should care about, time to delivery and quality of the product. My point is, as a corporate developer, if you discover a new paradigm of new way of doing things which lends to better software, how do you go about instituting the change. I think I was too broad when I said business stake holders do not care about the tools used. Like you said, Ruby and Rails have these idioms that when followed correctly help building solid systems. Like DHH said, Rails gives you test classes for items it creates so someone who is just starting out goes, oh, maybe I should be writing tests for everything and pretty soon they are writing better code, code that can be tested better because Rails sort of leads them dowm the right pathway.

  • Cursed Diamond « Greg A. Johnson’s Blog

    […] is what nourishes creativity, the essence of good problem solving. It is a result of home life, the tools you use, the tools that are available, the task at hand, and even the weather. Inspiration is impacted by […]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: