When one of my early projects where I had programmed by co-incidence ended I was really happy to move on to other things in life. Then suddenly, I was told to support the same project for a few more months and then a few more and then a few more.
On one hand maintaining my own code that sucked, made my life miserable. On the other hand however, it taught me how to take ownership of my code early on in my development life.
It taught me to set things right, by ruthless refactoring slowly with time, rather than just giving up or running away. Much like a painter who draws something that he thinks is really beautiful and then sells it at a price, I’ve felt a tinge of sadness in transitioning code over to the client in every other project after the one where I programmed by co-incidence.
Every now and then in my development career I’ve been involved with projects in and outside work where the primary project was migrating from one technology to another.
Migration projects at times are exciting. In migration projects it is implied that you will be spending a lot of time reading code (a skill every developer should cultivate) that folks from all over the world, who you may or may not have ever met or talked to have written. All you end up knowing is that months ago the clients hired a team of consultants. They wrote some code, transitioned it and have now moved on.
Migration projects have also exposed me to my share of Code Smell and snippets that would qualify for Daily WTF (now called worse than Failure).
Every now and then during my development career I’ve also met (and interviewed) a lot consultants. Of all the consultants that I’ve met, I’ve observed a particular kind very closely. Let’s call a consultant of this type – Fred.
Fred has the following peculiar characteristics:
- Fred usually works in short term billable projects.
- Fred gets very uncomfortable when he is asked to work in a project that will last for more than 5 months.
- Make Fred work in a long term Product that lasts for more than a couple of years that he would have to support and Fred becomes very nervous.
- Fred has a tendency to introduce Code Smell and writing snippets that qualify for “Daily WTF” every once-in-a-while.
Long story short, this type works under a philosophy that can be described in a line: Code, Hand over the code, Run and Don’t Look back!
As you dive deeper into Fred’s mentality you realize that there’s a little bit of Fred in all of us. Writing good code is all about getting rid of Fred! So what’s fundamentally wrong with Fred?
Fred is not really a bad programmer. Like all other good programmers Fred is struggling with the same issues we all struggle with: changing requirements, dead-lines, pressure from customer etc. What Fred lacks however is – ownership.
Fred Codes, Fred Codes More. Fred Hands over the code to the Client. Fred turns around and then Fred Runs as fast as he can, to another project. He doesn’t look back and he knows that he got away – Scot-Free! Year after year Fred continues to add “successfully transitioned” projects to his resume but doesn’t learn the art of Refactoring, the art of throwing away code and the art of elasticizing the iron triangle of software development . Big Design Up-front methodologies with no iterations help Fred tremendously in his Run-Away attitude.
An acquaintance in a 300 person process oriented CMM software consultancy house defends Fred - “but he successfully completed a project, right?”- Yeah. (I think I will not answer that question).
Actually, he doesn’t need to defend Fred because this discussion is not about criticizing Fred. Like I said, there’s a little bit of Fred in all of us. Do you have a little bit of Fred in you too?
The first step to getting rid of Fred is to cultivate a sense of code-ownership. Throw out a framework or a tool and commit to support it for at-least a few years. This could be a simple Accounting tool you write for your finance department or an open source project you start with a very small user base. The size of the project or lines of code aren’t important. Start by writing something that you are proud to support and maintain – for a very long time.
If you have posted articles / code out to the world, take time to support your code and content. Answer questions you get related to these. Don't abandon your content and code! Support it. If possible, Get involved in a longer project or product with support contracts.
In other words, learn to stand by your code, writing and words when they are released to the world. Learn to own and support them! Jumping from organization to another or jumping from one project to another, every few months, doesn’t take Fred anywhere in the long run.
Supporting what you write seems way simpler and practical than striving for utopia. It’s just a way of life which is really simple to achieve. I learnt it the hard way in a project early on in my career after which I promised to myself that personally, I would try my best not to write a single line of code I would feel sick about supporting. I think I’ve lived up to the promise, so far.
Once you learn it, you feel sorry for every other developer you meet who doesn’t “get it” – you start wondering how others who don’t follow the life-style survive. :) Years after that project, even today, I occasionally meet / see young developers who don’t get it. This results in the memories coming back to life and results in a post like this one. :)
These posts are just humble attempts to share my “lessons learnt” through past projects and other development experiences.
Either ways it’s always good to spend time reading code that’s written by people you don’t even know. Migration projects are a great opportunity to do just that.
“Fresh Canvas” projects are great opportunity to draw something new and inherently structured. It allows you to write code that’s relatively more organized.
If it’s a project where you are planting the seeds, nothing like it! But even If its legacy - it’s never too late to refactor parts of it; slowly. Throwing away old code that sucks without adding risk is an art - https://www.thousandtyone.com/blog/TheArtOfThrowingAwayCode.aspx :)
I’ve been at a project where we were hired for a month to add a new feature to an existing application. We ended up doing a 3 month rewrite of parts of the application where the old code just sucked, ended up getting paid and had a very happy client in the end. It just taught me that everyone loves quality - even the people who have to pay for it. :)
Either ways, my point was that if I (personally) write a single line of code, I should be happy to support at-least my code (every single line of it), for years to come if I have to rather than just writing for a “successful transition” where I have to turn around and run as fast as I can after that transition is over.
If every "Fred" on this planet just took ownership and responsibility of his own code the world would be a much better place. And that’s not too much to ask for from Fred. Don’t you think? :)
Like for example a project that ends today with the best MS technologies being used in it , like .net , wf ..... etc. will need to be supported for at least 2-3 years . Now the pace at which our technologies are changing will put Fred in a no man's land after he has supported this project for 3 years(bcoz these technologies which are best now will be as old as anything in nexct 3 years). I agree that Fred can learn himself , nobody stops him from learning newer technologies, but he cannot apply them except for sample Console Applications for his own.And this way he is never exposed to the real world.
>> I agree that Fred can learn himself, nobody stops him from learning newer technologies, but he cannot apply them except for sample Console Applications for his own.
And why exactly is that? Who is stopping Fred from writing an Open Source Application or building his own micro ISV during weekends and late nights if he is really enthusiastic about learning new stuff and putting it to good use?
It’s discouraging to see developers who are starting out in their career to be completely dependent on their organizations, clients, projects and other external factors in order to learn something new or do something innovative! Sometime even veteran developers make this mistake. I wrote a post on this - https://www.thousandtyone.com/blog/AreYouOnTheBench.aspx and https://www.thousandtyone.com/blog/TheThickSkinnedDeveloper.aspx .
If you think about it, the whole - “I-learnt-something-new-but-I-don’t-know-what-to-build-with-it” – argument seems like an excuse we developers make to ourselves to allow us the luxury of avoiding to build something decently big and complex till we - “have to” build something that’s decently big and complex.
If Fred learns windows workflow foundation and the only thing he can think of building himself after he has learnt it, is a hello world console application using windows workflow foundation then we should actually question the depth of his learning and not defend him by saying that the poor guy didn’t get a real life project to work on. Don't you agree?
>> And this way he is never exposed to the real world?
http://www.vertigo.com/familyshow.aspx - Technically this is just an “example application” to show the power of WPF. In reality it is as good as a real world application. I’m not sure how many “Freds” out there today would be able to build this quality of “real world” WPF application if they were approached by a client and told to build one. A Lot of them will be able to make a “successful project” that somehow “transitions” and uses WPF; but will it really use WPF like this application uses? I have my doubts.
DotNetNuke – built out of Starter Kit which was an “example application” to show the power of new technology (.NET) when it first came out. Today I would think that it’s much more “real world” than most projects the “Freds” of this world write. And it’s open source.
There are tons of other examples where an “example application” (or as you say – “Console Application” which is not “real world”) that someone wrote matured into a real life product which is awesome. I think I conveyed my point so I won’t type in the long list of these examples and increase this comment’s size. :)
On the other hand however, more than 65% (if you look for surveys on the net some of them give a higher number) of the “real world” projects fail. If you’re talking about Fred depending on his boss or a client to come and tell him what to build so that he can “really learn something new” and exercise his creativity, I doubt if he will ever learn anything new.
My take is that he would “somehow” use the new technology, make it look like it works and then rush to a different project so that he can learn something “newer and cooler” and make his resume flashier.
Like I said, this post wasn’t about criticizing Fred. There’s a little bit of Fred in all of us. This post was about getting rid of the Fred within all of us and putting things in the right perspective. It takes time and constant watering to develop deep and strong roots! Don’t you agree? :)
>> Now the pace at which our technologies are changing will put Fred in a no man's land after he has supported this project for 3 years
And who is stopping Fred from suggesting the use of new technology in the product he is supporting if he finds them appropriate? In a past project early on during my development career we started out with Datasets. During a 6 month support phase we realized that we were having maintenance issues, suggested the use of CSLA; showed the ROI to the client and got it done as a second phase of the same project. My point in the post was that Fred should stick to a project for some time, improve it, support it, stand by it when it does something it’s not supposed to do and above all, be responsible for it, rather than hopping from one project to another!
For open source projects like nUnit – there were just builds for .NET 1.1 a few months ago. Now there are parallel and specialized builds for .NET 2.0. Things like these clearly indicate that folks writing nUnit are supporting their code, standing by it and improving it! Of course, in the process of supporting what they write, they are learning new technologies too. Again, this is just one example. There are so many other projects which change with time. Old code is thrown away and new code is written. Like I’ve always said, throwing code is an Art – https://www.thousandtyone.com/blog/TheArtOfThrowingAwayCode.aspx :)
Months ago I wrote a small Atlas article on Code project. As Atlas matured folks started sending me emails (some of them were fairly angry emails :)) about my not updating the article and how my beta code was misleading them :). My article had started receiving some negative feedback because of that. Some of them even left comments there. Was any of that bad? No, it was awesome, because that forced me to revisit the RTM’ed version of ASP.NET Ajax and update my article. Supporting what you write (be it code, articles or anything) is always a win-win situation - for the client, for your organization, for your readers and above all for you!
Personally, I have always learned much more by supporting what I write than by writing it. This long comment is a classic example where I’m standing by my words (in the post) and writing a long comment to defend them. : ) Jokes apart, fixing performance issues, writing for usability and ruthless refactoring are arts you simply cannot learn till you push some code out to production and promise to stand by it when it doesn’t work the way it’s supposed to.
>> these technologies which are best now will be as old as anything in next 3 years
Yes. I agree. Technology is moving fast. Isn’t it? :) Does that mean we stop building long term projects or stop supporting them? That would an irresponsible thing to do! From academics and R&D perspective we need to learn new technologies and write perfect code, but in the real world we need to do something which is much more important – we need to ship – and continue to ship! I think the only answer is to ensure that your projects and products adapt to these new technologies version after version. Someone at Microsoft is still supporting Minesweeper – take a look at the vista version – it’s all WPF! :)
Bottom line – learning new technologies has nothing to do with not committing to a long term project; or supporting your code. In fact, supporting a project / product long term and learning new tools and technology are things that go hand-in-hand. They’re complementary, not conflicting!
Also, every time you learn a technology in-depth and commit to it, you are learning much more than the API and the tools. You are learning the concepts! Concepts I learnt during my BizTalk days are still very relevant to Windows Workflow Foundation. Picking up Windows Workflow foundation was a weekend’s affair because of these concepts.
I could go on-and-on with this but I think I’ve made the point. I think this long comment has also answered some ad-hoc emails that I’ve received about this post lately.
I kind-of realized that I was touching a controversial topic when I started writing this post but decided to go ahead and post it anyways. Until a discussion convinces me otherwise, I stand by every word I wrote in the post. :) I’ve also realized that this post is an excellent starting point for a lot of discussion. I would love to discuss more. Dear readers, post here and we can discuss! After all, “It is a sign of an educated mind to be able to entertain a thought without accepting it.” :)
>>>>
Now the pace at which our technologies are changing will put Fred in a no man's land after he has supported this project for 3 years
And who is stopping Fred from suggesting the use of new technology in the product he is supporting if he finds them appropriate?
>>>>
Now this isn't possible for every Fred to suggest clients , because maybe they are not in a position to do so.However there are other ways to learn as you have mentioned in your earlier points.
[While I was away from the blog, it appears there were some issues with the service provider. The blog may have gone down abruptly for a few hours. So if some of you tried to read during a time and got a runtime exception it was just something at the service provider’s end. Sorry! :)]
Dheeman, coming back to your point, honestly, I don’t understand it – so let me clarify for my own understanding.
>> Now this isn't possible for every Fred to suggest clients, because maybe they are not in a position to do so. However there are other ways to learn as you have mentioned in your earlier points.
And what do you mean by not in a “position to do so”? Do you mean not in a position to give suggestions that the developer feels will add value to his project and will result in a better product or solution for his client? If that’s the case I don’t even feel sorry for the developer and the team he is working with! They’re both in a big mess called communication gap! :)
I can understand a developer being abstracted from the end clients because of project managers, team leads and TA’s (I’m not saying that it always happens, but in large teams it can happen in the real world – a client may not know all 50 developers working on a project - that's fine!) but what’s stopping a developer from suggesting these technologies to his manager and the rest of the team?
And if it’s a pragmatic suggestion that brings a higher value to the project they can pass it on to the client. I’ve said this before – everyone likes quality, starting with product managers, to team leads to even the guys who pay money for it (clients).
If you’re remaining silent when you think you have a great idea or technology you can suggest, because you feel you’re not in a “position” to make a suggestion, you are doing a disservice to your client, your team and above all yourself!
Notice the use of word “suggest” – I’m not saying impose your suggestions forcefully or start a fight, but if you are in a team where you’re not allowed to give suggestions or speak your mind there are bigger problems you need to address first.
Seriously I tried hard, but I couldn’t think of one situation where a person can be “not in a position” to give a logical, pragmatic suggestion that he believes is true! Educate me – give me some examples (just for the sake of discussion)! Will you? :)
I can understand suggestions not being accepted – maybe the suggestions are wrong, maybe the others in the team don’t see the value they add immediately – that’s fine! Brainstorming is the fun part about software development! If you really believe you’re right, educate them. If you agree they are right, accept their argument and give up the idea.
Who says you have to be correct all the time? Who says your team needs to be correct all the time? But not being able to communicate is a problem! Feeling that you are “not in a position” to give suggestions might be a bigger problem than you think – in most cases that is how it starts and then it it’s leads to an “I’m not a part of the team” followed by “it’s not my job” followed by “who cares?” attitude!
Developers need to realize: the organization you work with is your company as long as you are associated with it. Changing it is your responsibility!
http://www.jamesshore.com/Change-Diary/ - The first line of the link sums up the basic idea – “You can Change Your Organization or Change Your Organization” :) But go ahead, read the full nineteen week diary and then let me know if the idea of “not in a position” to give a suggestion, even sounds remotely sensible. Becuase to me, it doesn't. :)
I’m not saying I have to be correct on this one, so I’m open for discussions and “suggestions” – but like I said, till I find a convincing argument to make me think otherwise, I stand by every word in this post! :)
case 1: I've seen many people (read project top-shots like pm,tech lead,associate pm) not willing to move out of theire ideas in terms of tenchinal solutions.One of my colleagues and a old aquaintaince of mine had suggested a much better .net way of writing things becasue he was more eager to write .net code rather than writing vb6 [ a bit of Fred :)]. But his ideas were put to the bin immediately citing reasons that none of the top-shots are confident in .net webservices and so they do not want to risk if any unusual situation arrive.[don't think that the .net way was not technically possible.]
case 2: Most decisions(technical,like how it will be done,using which tech,etc...) are done by project think-tank (usually a small group) and in more than 90% of the cases the developer who actually implemenets the code is not even aware that such a technical decison is being taken , which he has to implement later on.Now (without any personal offences) it may happen that the person/persons entrusted to take the technical decision may not be as up-to-date with newer technologies as you are.There creates the problem. When you get the solution matrix or the technical specification (a document containing what to do, even the pseudo-code,and how to do ) you find that many things can be done in a much better way that the doc contains, but then if you carry on suggesting that , people (read project top-shots and the think-tank) will strongly defend that you cannot do it becasue they do not know that the problem can be solved by the way you are suggesting.I'm not suggesting that the solution matrix or the technical spec. conatins contains something that is wrong, but it contains something that is not the best way to solve the problem. The project has the scope of implementing the problem using your way but you cannot do it becasue THEY do no think that it can be done.
Actually, rajiv, i understand your view-point because I've worked with you. And you have a good reason to believe in that.Bust consider the above situations an think-- "you are not always in a position" to suggest.
"Changing your organization" is not possible in this case, because this is going on for years.. and these days people tend to "You can Change Your Organization" to avoid such things.
I agree, with you that it's the environment that creates or destroys whatever you are trying to suggest in this blog post...It creates a "I will do whatever they suggest, who cares what happened later on"
Now, you are giving me food for thought and re-confirming my beliefs in my post even more – so let me start by saying a big fat thank you! :)
As usual, let me answer one line at a time.
>> Case 1: I've seen many people (read project top-shots like pm, tech lead, associate pm) not willing to move out of their ideas in terms of technical solutions. One of my colleagues and a old acquaintance of mine had suggested a much better .net way of writing things because he was more eager to write .net code rather than writing vb6 [ a bit of Fred :)]. But his ideas were put to the bin immediately citing reasons that none of the top-shots are confident in .net web services and so they do not want to risk if any unusual situation arrive.[don't think that the .net way was not technically possible.]
I don't see this as a valid example. Your buddy was (in your own words) "eager to write .net code" so he went out and suggested .NET. The entire team wasn't familiar with .NET so they rejected it. Big deal! This happens all the time. I quoted similar examples at - https://www.thousandtyone.com/blog/AreYouOnTheBench.aspx.
In fact, the way you state the example, I think it was completely correct on the Team's part to put his idea to the bin if they were not a .NET shop. 1 Person in the team is "eager to" write .NET other 9 don't know anything about .NET. What were they supposed to do? Ask the other 9 stay back every night to learn .NET? Maybe the organization and the client didn't want to spend the additional cost of training people in .NET. Were they expected to do that just because your buddy was eager to write some .NET code? The real world doesn’t work that way.
In the real world a lot of things that are “Technically possible” are not done in reality because people have to worry about so many other things. A mentor once remarked – “only a small percentage of software development is about technology” – I think he was correct. So if the team dumped your friend's idea in the dust bin because they were managing risk and ensuring project success, I agree with them!
There are so many COBOL programs running out there even today. There are many COBOL companies and shops out there writing / maintaining this code. Are they supposed to become .NET shops overnight just because a .NET developer joins them and is eager to write .NET code?
Having said that, my post wasn't about working in COBOL shop. My post was about supporting what you write and then growing with your code. If your buddy isn't happy working on VB6 than he shouldn't be working in a VB6 shop! Period.
Long story short, if he is really eager to write .NET code, he shouldn’t be working in a company where 9/10 people are not confident with .NET! He should change (either his project or his organization), as quickly as he possibly can.
>> case 2: Most decisions(technical, like how it will be done, using which tech, etc...) are done by project think-tank (usually a small group) and in more than 90% of the cases the developer who actually implements the code is not even aware that such a technical decision is being taken , which he has to implement later on.
Bull-shit! (Sorry about the language, as you can see I feel a little passionately about this topic :)) – Seriously, You are comparing one or two multi-thousand body firms which may be nothing more than body-shoppers in India and using their example to represent that in “90%” of the cases developers are like laborer who just lay down the bricks without using their head.
I have some problems with this statement. I consider myself a developer at heart and take some offence at this statement (even if it may be statistically correct).
Here are some more statistics – more than 70% of the projects undertaken fail – does that mean as developers we start quoting that figure as an excuse for all our future failures? Even if the statistics are correct, our focus should be on making sure that our projects are on the 30% side.
Similarly as developers we should be working really hard so that we are in the 10% side of developers who don’t code like laborers. There are three kinds of lies – black lies, white lies and statistics. So I don’t buy the whole “90% of the cases” argument even if it’s statistically correct. (And honestly, I’m not even sure if that is statistically correct.)
In fact, I beg to differ completely from this statement. Any decently good developer worth his salt that I’ve ever worked with has “demanded” that he knows the basic overall picture before he starts writing code else he just refuses to write code.
At work recently, a couple of engineers requested that they want to be a part of every sprint meeting and design meeting just because they want to be a part of the decisions being made (you know most of them because you’ve worked with them in the past too).We decided to invite them in all future meetings. At a couple of client places I’ve made similar requests and I’ve been invited to give my opinions too.
Coming back to your “think tank” argument - The goal here is to be either a part of a team that is Agile or become a part of the think tank by developing some roots in an organization by being a part of the organization for a few years. This actually proves my point to sticking to an organization and a project for a couple of years, so I don’t see how this is an argument against my post. The way I see it, this argument actually does in my favor, doesn’t it?
>> Now (without any personal offences) it may happen that the person/persons entrusted to take the technical decision may not be as up-to-date with newer technologies as you are. There creates the problem. When you get the solution matrix or the technical specification (a document containing what to do, even the pseudo-code, and how to do) you find that many things can be done in a much better way that the doc contains, but then if you carry on suggesting that, people (read project top-shots and the think-tank) will strongly defend that you cannot do it because they do not know that the problem can be solved by the way you are suggesting. I'm not suggesting that the solution matrix or the technical spec. contains contains something that is wrong, but it contains something that is not the best way to solve the problem. The project has the scope of implementing the problem using your way but you cannot do it because THEY do not think that it can be done.
On the personal offence part, No way! I’m pretty thick-skinned and don’t take offence easily :). In fact I take what you said as a compliment rather than taking offence. :) Having said that, how can you be so sure you are suggesting a “better” way than was in mentioned in the solution matrix? They think their way is correct, you think yours is correct. That’s software development! In fact, that’s life!
Either ways, there's a difference between having a difference of opinion and working with morons. When I read your comment above it just tells me a few things. If a developer ever finds himself in such a situation such as the one you describe above – here’s what I clearly see:
1. I can clearly see lack of agility in the team that you describe above.
2. I can clearly see lack of openness.
3. I can clearly see lack of communication.
4. I can clearly see just too much process and beurocracy.
I can clearly see that in a team of this sort it is apparently very difficult to write good code, leave aside supporting it. My post assumed that you would write some good code to begin with before you support it for years. My post assumed a decent work environment where people are open to ideas.
If those are missing then you're probably talking about a team of people who most probably won't even be reading this post, so no wonder this post wasn't written keeping them in mind. :)
Yes there are so-called body-shops and companies around the world (especially in India) where some crazy problems do exist but then there are too many mental asylums in this planet (and two really big ones in our country :)).
Should I worry about all the mental asylums while writing my post? Maybe I should, but I don't. Actually, I would rather not worry about them in my posts unless I have to be a part of such a team. :)
On a serious note, I don’t think any organization can be as bad as you make it sound. Human beings in general are good people who are willing to listen to new ideas and learn. You just need to show them the benefit, money or ROI! You just have to speak their language and help them understand. And if after repeated tries you can’t change your organization than you “change it”. Right? :)
I think we went on a tangent from the original content of the post :) but then, like I said, if Fred does find himself in a mental asylum like the one you describe above, he can change his company or he can change your company.
>> Actually, Rajiv, I understand your view-point because I've worked with you. And you have a good reason to believe in that. But consider the above situations and think-- "you are not always in a position" to suggest.
I agree. If one fine morning a developer finds himself in a mental asylum tied to a bed, mouth gagged of-course he is not in a position to suggest! I was just suggesting that as developers he doesn’t really want to be a part of a mental asylum where no-one speaks his language unless he really "has to". I don't see a lot of reasons why anyone "has to" be a part of such an asylum for a very long time but then I could be wrong. Who knows! Maybe you can explain why your friend in still in that same organization even when all his ideas are constantly going to the bin?
>> I myself was entrusted to write a web service with authentication, when you are sending your username and clear-text password in every web-service method call. I went on suggesting that this is equivalent to almost no authentication, and is susceptible to attacks, and this can be achieved using WSE toolkit easily. But then :(..... (Pls. guess, I’m tired of writing :), just kidding)
So, people differed in opinion than what you suggested. Big Deal! I can mention many similar examples where other members of the team and I have differed in opinions at work. At times I’ve changed to accommodate their ideas and at times they’ve changed to accommodate mine. That's the way we make good software! Maybe your web service was an intranet web service and there was no need for making it secured? Maybe you were right and you should have argued a little bit more. I think you are confusing my post and trying to say that every time people don’t listen to me they are morons. I don’t think I agree to that approach.
If you are constantly stating the right approaches and people are differing in approach becuase of ego's and complexes, either educate them or find an organization where people will understand your approaches better. Either ways, one or two isolated examples like the ones you mentioned barely mean anything!
>> I agree, with you that it's the environment that creates or destroys whatever you are trying to suggest in this blog post...It creates a "I will do whatever they suggest, who cares what happens later on"
Yes, and I also firmly believe that every individual chooses his environment based on his priorities. So the environment doesn’t alone creates or destroy what I am trying to suggest in this post. At the end of it, it’s our attitude that creates or destroys what I am trying to suggest in this post. People with a good attitude towards development will find ways to work around these issues or they will find a different organization that values and understands their talent.
>> "Changing your organization" is not possible in this case, because this is going on for years… And these days people tend to "You can Change Your Organization" to avoid such thing.
Again, I beg to differ here. (You should really read the whole diary – the link I posted on my earlier comment).
Actually, the world is not really as rosy as you claim. Trust me; I've been taking a lot of interviews lately. "These days" I see most friends and acquaintances change jobs for reasons which have nothing to do with Job satisfaction as you claim in your arguments!
I make it a point to ask candidates why they are leaving their current job in the interviews I conduct, and I've heard reasons for job changes in tons of interviews that I take every month and documented them at - https://www.thousandtyone.com/blog/AreYouOnTheBench.aspx
Trust me, out of every 10 people (especially Indians) who "change their company" - 9 change them do it for a higher salary, onshore opportunity, a big brand name etc. They have nothing to do with work satisfaction and becoming a better professional, as you claim in your comment – most of them are not even frustrated with their companies. They just go looking for a job-change because the “market is good” – again, I analyzed this behavior patterns in developers and wrote a post about this at https://www.thousandtyone.com/blog/AreYouOnTheBench.aspx.
If people just changed jobs work satisfaction and similar reasons these so called mental asylums where your friend worked, as you describe above would automatically cease to exist or change their way of operating because of lack of employees but maybe “that’s” asking for utopia of development in the Indian context! - :)
So,
Sorry. You’ve still not convinced me :) – I still stand by every word in this post. But these discussions are real good food for thought. They are just making me think in a structured way about what I have always believed in and the process of putting them down in writing is really helping me.
Thanks for giving me more food for thought. I’m still hungry! Dear, Reader(s) – more thoughts? I would love to discuss. Post your thoughts as comments – I would love to “support” my post and answer them :).
>>>There are so many COBOL programs running out there even today. There are many COBOL companies and shops out there writing / maintaining this code. Are they supposed to become .NET shops overnight just because a .NET developer joins them and is eager to write .NET code?
Having said that, my post wasn't about working in COBOL shop. My post was about supporting what you write and then growing with your code. If your buddy isn't happy working on VB6 than he shouldn't be working in a VB6 shop!
Rajiv I agree that 1 out of 10 will have to change. But in the first place I would like to ask you whether you support the idea of hiring a .net developer in a COBOL shop, to make him work in COBOL, because in the market you do not have readymade COBOL guys available??
Nextly I'm never talking about a vb6 shop .. ,but he is put in a project that has both vb6 and .net. Therefore, it's not about 9 people learning .net , or client not wanting to implement .net,it is already there, but 9 people are not confident in .net, so they do not implement .net. I see this plain and simple why-should-I-learn-when-I-am-earning-bucks-without-it syndrome.
>>Bull-shit! (Sorry about the language, as you can see I feel a little passionately about this topic :)) – Seriously, You are comparing one or two multi-thousand body firms which may be nothing more than body-shoppers in India and using their example to represent that in “90%” of the cases developers are like laborer who just lay down the bricks without using their head
I guess you are correct in assuming that this things reside in
.. 1, multi thousand companies
..2, body-shoppers
..3,services industry companies again with huge workforce..
and that that figure of 90% is true there..
>>
Either ways, there's a difference between having a difference of opinion and working with morons. When I read your comment above it just tells me a few things. If a developer ever finds himself in such a situation such as the one you describe above – here’s what I clearly see:
1. I can clearly see lack of agility in the team that you describe above.
2. I can clearly see lack of openness.
3. I can clearly see lack of communication.
4. I can clearly see just too much process and beurocracy.
That was a nice catch...
Yes difference ca always be there, we always have.. but don't you think that for the purpose of the project ( being within the project constraints) the best solution should prevail??
>>>
So, people differed in opinion than what you suggested. Big Deal! I can mention many similar examples where other members of the team and I have differed in opinions at work. At times I’ve changed to accommodate their ideas and at times they’ve changed to accommodate mine. That's the way we make good software! Maybe your web service was an intranet web service and there was no need for making it secured? Maybe you were right and you should have argued a little bit more. I think you are confusing my post and trying to say that every time people don’t listen to me they are morons. I don’t think I agree to that approach.
No it's never a BIG DEAL.. and they are not morons becasue they did not pay heed to my suggestions. It's never that way, because there can be n number of times where I might suggest a worse suggestion. But then, you can count on me in this case, atleast. and taking about arguement, what for should I argue ? Rajiv, when arguing may be considered as a attitude problem , I rather not argue and look for a place that suites my attitude. Shouldn't you have done that?? Or you have continued arguing that you are correct and they are wrong..???
>>
Trust me, out of every 10 people (especially Indians) who "change their company" - 9 change them do it for a higher salary, onshore opportunity, a big brand name etc. They have nothing to do with work satisfaction and becoming a better professional, as you claim in your comment
I agree, and how couldn't I :) You know that.....
..
So,
Our differences are minimising with every post , except for a few instances , may be
because I have worked in companies like that or I know these a little bit better than you do..
Anyway this tiem I should give you a big THANK YOU for a large reply .
>> But in the first place I would like to ask you whether you support the idea of hiring a .net developer in a COBOL shop, to make him work in COBOL, because in the market you do not have readymade COBOL guys available??
What I support or don't support doesn't matter. The reality is that if a huge monolithic firm needs a COBOL developer and there aren’t any available out there they “will” hire a .NET developer and make him a COBOL developer if he’s willing to join as a COBOL developer!
- Will the .NET developer accept the offer?
- Will he continue doing COBOL development for a long time?
- Will he get fed up and move on?
These are individual choices that every developer has to make depending on his priorities and choices. I for once, have no intention or power to influence a single soul’s decision. So, whether I support the idea or not doesn’t mean anything. Seriously!
>> I'm never talking about a vb6 shop..., but he is put in a project that has both vb6 and .net. Therefore, it's not about 9 people learning .Net, or client not wanting to implement .Net, it is already there, but 9 people are not confident in .NET, so they do not implement .Net. I see this plain and simple why-should-I-learn-when-I-am-earning-bucks-without-it syndrome.
So are you saying he’s in the right company, the right project (since you say it has both VB and .NET) but the wrong team? Or are you saying he’s working on the wrong module and he should be working on a .NET parts?
Either ways, it’s very evident that the others in his team are not going to switch to .NET. Just because he is eager to do so! Imposing that decision on others is not such a good idea. Maybe they won’t be able to pick up .NET in such a short time. Maybe the project will fail miserably. Maybe the organization is “managing risks” by letting them work on VB6 and ensuring project’s success. Who knows! These things happen in the real world.
Either ways, one thing is very evident, his interests and his organizations interests aren’t aligning. Bottom line is, if things aren’t working out for him, he needs to stop cribbing and go find himself another job.
>> I guess you are correct in assuming that these things reside in... 1, multi thousand companies...2, body-shoppers...3, services industry companies again with huge workforce... And that that figures of 90% is true there...
Honestly I haven’t seen a white paper or a study that states that “90%” of the multi-thousand body shoppers have communication and beurocracy issues but I take your word for it and assume that the number is correct (if you’re saying it’s correct :)). But then the 75% of the projects fail is a statistical fact. If you Google there are tons of links out there that will take you to reputed sources.
Either ways, like I said, these numbers mean nothing to me and they should mean nothing to you. As developers we should just strive to be on the 30% side when writing software and the 10% side when looking for an organization! Again, I think we went on a tangent and this has nothing to do with my original post. Personally, I have nothing against companies with huge work force. I just dislike body shops; and that too is just my personal opinion. :)
>> Yes difference can always be there, we always have... But don't you think that for the purpose of the project (being within the project constraints) the best solution should prevail??
Two thoughts:
Thought one:
Best is relative. What may be best to you may not be best for me (or best for the rest of the team, or best for project or best for clients). As a TA I make recommendations for technologies in projects. At times clients come out and tell me that they don’t want to upgrade to the latest version of SharePoint because cost of migration is an issue. From my perspective I’m proposing the “best” solution but they don’t “need it” – you have to learn to respect that!
Definition of quality is not providing the “best” solution. Definition of quality is “conformance to requirements” – which means that if the rest of the team is SharePoint 2003, the clients wants 2003, the maintenance team is 2003, you explain the Pro’s and Con’s of not moving to 2007 to them and then give them the best SharePoint 2003 application possible. Simple.
Thought two:
Something to think about - Best solutions prevail in best of environments.
>> Rajiv, when arguing may be considered as an attitude problem, I rather not argue and look for a place, that-suites my attitude?
I was never suggesting you slap your manager and make a scene. :) Obviously it’s rather better to look for a place where personal interests are a little more aligned with the organization’s interests.
>> I agree, and how couldn't I :)
Jokes apart, seriously, I actually asked that question to around 10 or so odd developers during interviews and just 1 or 2 of them were looking for a change for reasons other than salary hikes, bigger brand etc. the other 8 or 9 or so were very focused towards salary, on-shore travel, brand-name and other factors which had nothing to do with software development.
>> Except for a few instances, May be because I have worked in companies like that or I know these a little bit better than you do…
Do you? :) I don’t want to turn this into “whose-past-sucks-more” contest but try imagining being a part of a meeting after a failed venture where the culprit would be found and eventually fired and everyone is pointing fingers at each other to save their job. With one of the first Indian companies that I ever worked with, those meetings were real. Ever seen employees that are so frustrated that they start stealing RAM and other hardware out of office machines? At one of the clients of one of the first companies I ever worked with that was a reality.
If I place work environment, work culture, ethics, passion for what I do, teamwork, working with smart individuals I can respect, mentors that have motivated me and have earned my respect and above all, self respect, over a pay-check there are off-course reasons behind why I do that. These are not just buzz words that I’ve picked from text-books.
Everyone likes to think that they’ve learnt a lot from their past experiences and I’m just a normal human being :) - On a serious note, I would hate being a part of such an organization as the one I describe ever again, but I thank god for teaching me these basic fundamental lessons early on in life. Seriously, the values that I talk about aren't things that have just been stolen from text-books. :)
>> Our differences are minimizing with every post, except for a few instances?
Differences are good. They indicate individuality and the ability and character to have opinions! It is the sign of an educated mind to entertain a though without accepting it, remember? If you have more thoughts or difference of opinions I welcome them. :)
What I support or don't support doesn't matter. The reality is that if a huge monolithic firm needs a COBOL developer and there aren’t any available out there they “will” hire a .NET developer and make him a COBOL developer if he’s willing to join as a COBOL developer!
I've seen very recently at least 5 instances where people being taken in for positions of ASP.NET after a long grinding interview solely based on .net and then when they join they are being put into projects that don't even have a sniff of .net, neither they are related to .net. And believe me , this 5 instances does not belong to one single company, they belong to different companies. So if the COBOL shops gives an ad for an open ASP.NET position and a developer joins them, does it mean that the developer is "willing to join as a COBOL developer". And is the developer worng in being frustrated seeing all this? (though, i agree that it depends from person to person)
>>>Best solutions prevail in best of environments.
I agree to that
Bottom line is, if things aren’t working out for him, he needs to stop cribbing and go find himself another job.
So aren't you suggesting "Change your Organization" in this scenario?
>>> Ever seen employees that are so frustrated that they start stealing RAM and other hardware out of office machines?
Yes seen that here in IBm for the first time in my life. Though I don't know who has stolen the RAM, it has happenend to a member of my team, that too during normal office hours.(My dad, hearing this incident told me that this is worst possible environment...what do I say :( )
>>Differences are good. They indicate individuality and the ability and character to have opinions! It is the sign of an educated mind to entertain a though without accepting it, remember?
Posts are getting smaller :) differences are minimising... , but all after a good bit of thought exchange.
>> I've seen very recently at least 5 instances where people being taken in for positions of ASP.NET after a long grinding interview solely based on .net and then when they join they are being put into projects that don't even have a sniff of .net, neither they are related to .net.
What you are referring to is often referred to as "soft bench", which means that if a .NET project comes by, these guys will be utilized for .NET. Till then they are given anything and everything that is available. I'm not saying if that's right or wrong. Just saying it's a normal practice in many companies and if I look at it from the organizations perspective, I don’t see anything wrong with it. Like I said, it’s every individual developer’s personal choice if he wants to be a part of this “soft bench”.
>> So aren't you suggesting "Change your Organization" in this scenario?
Off-course I'm! How bluntly can I say it? :) But that's just my opinion.
>> Yes seen that here in IBM for the first time in my life. Though I don't know who has stolen the RAM, it has happened to a member of my team.
Dheeman, I was talking about a very small 10 person company where I worked during the early part of my career. I had no idea this was a common thing in Indian development centers of other companies too. Honestly, I just find it really hard to buy or digest that something like this would happen at IBM.
Either ways I've never worked at IBM but I've been told by a couple of guys that they're a decent organization and I don't think it's fair to criticize IBM as whole based on actions of a particular individual even if something like this happened. Maybe this was just an isolated incident in your case.
Honestly, this is getting a bit too controversial for an online discussion, and I don't feel comfortable using this blog as a medium point fingers and slam organization(s) or individual(s) I know nothing about.
>> Posts are getting smaller :) differences are minimizing..., but all after a good bit of thought exchange.
So, did I change your thoughts or did we just entertain thoughts without accepting them? Because I know, none of my thoughts changed after this discussion and I still stand by every word in the post! :)
Seriously, I'm getting a little tired of typing on this same discussion thread and I think we’ve gone on a tangent that’s far away from the actual topic of the post. So call me or let's meet for a quick brunch or some snacks on Monday if you want to carry this discussion forward.
a bit controversial too..
I would be nice to have some snacks with you. I would call you up, once
I'm a bit free. , may not be today..
Anyways you did change some of my thousght, that's for sure...
Comments are closed.