Have you ever worked for an “over appreciative” boss that uses thank you, great job, awesome job etc. in abundance. If you have you will understand where I am coming from.
When we put ourselves on the line for someone else then a heartfelt thank you is in order; when we deliver a piece of work that is truly impressive because of its superior quality, the efficiency with which it was carried out or some other measurable factor then a "great job" would be appreciated...getting recognized in these cases is necessary, it makes us feel good, it motivates us to do it again, it works.
On the other hand, if you thank me for simply doing my job and praise my average work as awesome it does not work. Most likely the insincerity of your “thankfulness” will be obvious and that will not help, your praise will be meaningless and your “troops” will think of you as a manipulative person; they will start despising you. In the rare cases when you may be so good an actor that you come across as sincerely appreciative the “troops” will consider you an incompetent dummy that has no clue what a good job is and what the responsibilities and duties of the troops are and you will inadvertently cultivate a culture of mediocrity.
So, to all you bosses out there, do yourself and your organization a favor and don't thank me when I am simply doing my job! I am not doing it for you, I am doing it for me; I am doing it because I want to keep my job... don't ever say thank you because you think that is your job to do, only say it when you really mean it! Don’t praise my work because its your job to do that, only praise my work if you truly believe its outstanding. Most of the time let me do my job and you do yours and we don’t need to thank each other; that’s ok, it works.
From the practical point of view however, things are not as clear cut as I am presenting them to be – people are all different and a good boss will need to consider those differences. An inexperienced employee who lacks confidence may need constant re-assurance that he is doing a good job; an emotionally un-stable individual may need re-assurance that the boss is not out to get him; yet another, just wants to be left alone; and so on, and so on… it is not easy to be a boss; people are all different, they come from different cultural backgrounds, they have received widely varied educations, different experiences have shaped them; in short, they all “speak a different language” and managing a group of them effectively is a delicate balancing act.
Thursday, December 13, 2007
Wednesday, December 12, 2007
Outsourcing the Government
The Governor of our beautiful state of Georgia, which I am sure is on everyone of y’all ‘s minds (the state that is, not the Governor), announced yesterday that he is outsourcing all of state’s IT to the private sector - about 1,100 jobs will be affected by the move.
I am not a believer in outsourcing the whole Government and I am especially against the Blackwater type outsourcing the risks of which, in my mind, way outweigh the potential benefits, however, when it comes to specialized auxiliary services that the government needs, like the IT, I am a strong advocate of outsourcing. We live in a highly specialized society – we all specialize in a narrow niche and try to be the best at it, we don’t try to take care of our needs ourselves - maybe if you are an IT person you tinker around with computer issues yourself, or if you are a plumber you fix your own plumbing but generally speaking we let the experts provide to us the services we need while we provide our expert services to others.
The Government, as do many other organizations and as do we as individuals, often falls in the trap of “we can do it cheaper and better ourselves” – yes, there are cases when doing it yourself makes perfect sense, we don’t need to get into that, but, as a general rule especially for the Government doing yourself is not the best way unless it is your core expertise and responsibility.
Let’s focus on IT services for the Government, the subject that triggered this writing. Following you will find some of what I think are the disadvantages of Government handling IT itself:
- lack of flexibility/agility to respond to today’s fast changing technology – for private enterprises their very survival depends on that ability to respond quickly to the changing environment whereas for the government survivability is not an issue – removing that factor from the equation you have removed one of the strongest motivators for an organization and its people;
- lack of expertise – not only has the government with its pay scale a harder time recruiting and retaining top talent unless they have already started thinking of retirement, but even if it does manage to hire top people it lacks both the resources and motivation to maintain and raise the level of expertise;
- entitlement burdens weigh heavily on the Government’s budget – a tenured government employee simply needs to show up at work (a bit of exaggeration here probably but it helps make the point J) – don’t know if there are any studies that correlate productivity of employees with job security but I would bet that job security lowers motivation to perform and productivity suffers as a consequence;
- lack of attention - IT is just one of the services the Government needs to function but it is not in the list of core/primary functions of the government and therefore does not get the attention it needs/deserves with probably the exception of high impact, high exposure projects that may affect the image of the Government in the eyes of its people;
Now, a private organization focused on IT services, like an IBM or Accenture, must prove itself every day, they must show that they are at the top of their game or they are out. IT Services are the core of their business; they directly and significantly impact their bottom line. They must constantly work in improving their processes and procedures to make them more efficient otherwise someone else will come along and take their place. They have virtually no entitlement burdens; they can recruit and keep top talent as long as it performs. They are exposed to multiple widely varied scenarios and the expertise gained in one scenario is put to good use in other scenarios instead of getting “shelved”. Their cost of gaining the expertise is spread among multiple clients, for example, a top security expert in a “closed” IT department is only using his high level expertise 20% of the time whereas the rest of the time is dealing with other work that does not require his expertise, whereas on an IT services company he will be “floating” between multiple clients and his expertise will be efficiently utilized 100% of the time.
There are many more advantages that the private sector enjoys over the Government but in short, it seems to me that it makes a lot of sense for the government to outsource IT to the private sector.
I know, a lot of people out there will argue that the Government will end up spending a lot more than the $617 million per year (in the case of Georgia) that it spends now, and that is possible. But, I would say there are only two explanations for an increased cost – either the Government will receive higher quality and more services than it receives now from its own IT department OR they will award contracts on a non-transparent and un-fair way – otherwise the free market forces at work will result in lower costs to the Government (the people that fund the government).
This is just a personal opinion – no intention to offend anyone who works in the Government sector or to speak on behalf of IT services companies. I am indeed open to reason and can be convinced otherwise, so leave your comments here.
I am not a believer in outsourcing the whole Government and I am especially against the Blackwater type outsourcing the risks of which, in my mind, way outweigh the potential benefits, however, when it comes to specialized auxiliary services that the government needs, like the IT, I am a strong advocate of outsourcing. We live in a highly specialized society – we all specialize in a narrow niche and try to be the best at it, we don’t try to take care of our needs ourselves - maybe if you are an IT person you tinker around with computer issues yourself, or if you are a plumber you fix your own plumbing but generally speaking we let the experts provide to us the services we need while we provide our expert services to others.
The Government, as do many other organizations and as do we as individuals, often falls in the trap of “we can do it cheaper and better ourselves” – yes, there are cases when doing it yourself makes perfect sense, we don’t need to get into that, but, as a general rule especially for the Government doing yourself is not the best way unless it is your core expertise and responsibility.
Let’s focus on IT services for the Government, the subject that triggered this writing. Following you will find some of what I think are the disadvantages of Government handling IT itself:
- lack of flexibility/agility to respond to today’s fast changing technology – for private enterprises their very survival depends on that ability to respond quickly to the changing environment whereas for the government survivability is not an issue – removing that factor from the equation you have removed one of the strongest motivators for an organization and its people;
- lack of expertise – not only has the government with its pay scale a harder time recruiting and retaining top talent unless they have already started thinking of retirement, but even if it does manage to hire top people it lacks both the resources and motivation to maintain and raise the level of expertise;
- entitlement burdens weigh heavily on the Government’s budget – a tenured government employee simply needs to show up at work (a bit of exaggeration here probably but it helps make the point J) – don’t know if there are any studies that correlate productivity of employees with job security but I would bet that job security lowers motivation to perform and productivity suffers as a consequence;
- lack of attention - IT is just one of the services the Government needs to function but it is not in the list of core/primary functions of the government and therefore does not get the attention it needs/deserves with probably the exception of high impact, high exposure projects that may affect the image of the Government in the eyes of its people;
Now, a private organization focused on IT services, like an IBM or Accenture, must prove itself every day, they must show that they are at the top of their game or they are out. IT Services are the core of their business; they directly and significantly impact their bottom line. They must constantly work in improving their processes and procedures to make them more efficient otherwise someone else will come along and take their place. They have virtually no entitlement burdens; they can recruit and keep top talent as long as it performs. They are exposed to multiple widely varied scenarios and the expertise gained in one scenario is put to good use in other scenarios instead of getting “shelved”. Their cost of gaining the expertise is spread among multiple clients, for example, a top security expert in a “closed” IT department is only using his high level expertise 20% of the time whereas the rest of the time is dealing with other work that does not require his expertise, whereas on an IT services company he will be “floating” between multiple clients and his expertise will be efficiently utilized 100% of the time.
There are many more advantages that the private sector enjoys over the Government but in short, it seems to me that it makes a lot of sense for the government to outsource IT to the private sector.
I know, a lot of people out there will argue that the Government will end up spending a lot more than the $617 million per year (in the case of Georgia) that it spends now, and that is possible. But, I would say there are only two explanations for an increased cost – either the Government will receive higher quality and more services than it receives now from its own IT department OR they will award contracts on a non-transparent and un-fair way – otherwise the free market forces at work will result in lower costs to the Government (the people that fund the government).
This is just a personal opinion – no intention to offend anyone who works in the Government sector or to speak on behalf of IT services companies. I am indeed open to reason and can be convinced otherwise, so leave your comments here.
Tuesday, December 11, 2007
Programmers significantly underpaid
I met a friend the other day, an excellent programmer who told me he was going to law school and the main motivation for that was apparently money. It made me ask myself the question: “are the programmers underpaid? “.
I started recalling all the IT groups I have been involved with in the last 15 years and then I also spent a bit of time looking at job boards to see what kind of compensation is being offered for programming positions. After spending a couple of hours thinking about it I concluded that the answer to “are the programmers underpaid?” is both YES and NO and the reason for that is the word programmer which is not specific enough.
In the real World there are two groups of programmers:
- the real programmers – those who have a solid knowledge of the theoretical foundation of the computer science, the ones who truly understand “the stuff”, the ones who get it done quickly and efficiently and do it right the first time, the ones who represent only 20% of any IT department out there but carry 80% of the load - in short those guys and gals are the ones who know what they are doing;
- the pretend programmers – those are the ones who lack understanding of basic principles, who tinker around for weeks with projects that should take hours, ones who usually master the art of “pretending to be” and are capable of presenting themselves as being highly knowledgeable to an audience that is not capable of probing deeper than the thin layer of knowledge that they have. Those are the fortunate ones who have gotten a “lifetime scholarship” on the IT department of some organization.
After coming up with this classification the answer to my question became crystal clear: the real programmers are significantly underpaid (see the argument below), while the pretend programmers are overpaid. In total as a big group of programmers they are apparently fairly compensated – after all it is the free market that has dictated the levels of compensation we see today.
So why do I think real programmers are underpaid? Well, here is my simple calculation: let’s take an average salary of $80K / year and divide it by 52 weeks that rounds to about $1.5K per week. Now, a real programmer, as I am sure you all know, puts in an average of 60 hours of work per week (not accounting here for the fact that even after those 60 hours he/she is still thinking and reading about how to deal with a challenge, how to more efficiently handle a process etc.) – that translated to a pitiful $25 / hour. Some may disagree with me on the “pitifulness” of the $25 / hour considering that the minimum wage posted on our office hall says $5.85 / hour, but, I can bring plenty of examples to support my statement – examples like my cousin who just started working for a railroad company on the maintenance and makes $27 / hour (mind you no experience and no education) or my next door neighbor (lawyer with experience and education) who won’t start talking for less than $300 / hour. So, where does a real programmer fall in this wide spectrum of abilities and compensations – what I know is that if you consider the intelligence, the education, the sheer amount of work they have put into gaining that education the real programmers are at the top of the spectrum but unfortunately, when it comes to compensation they are between the McDonalds kids flipping burgers and skilled laborers! Sad!
So, what is wrong with this picture and what can one do to correct it? Well, I will leave that for another day – for now, I will go ask for a raise :)
I started recalling all the IT groups I have been involved with in the last 15 years and then I also spent a bit of time looking at job boards to see what kind of compensation is being offered for programming positions. After spending a couple of hours thinking about it I concluded that the answer to “are the programmers underpaid?” is both YES and NO and the reason for that is the word programmer which is not specific enough.
In the real World there are two groups of programmers:
- the real programmers – those who have a solid knowledge of the theoretical foundation of the computer science, the ones who truly understand “the stuff”, the ones who get it done quickly and efficiently and do it right the first time, the ones who represent only 20% of any IT department out there but carry 80% of the load - in short those guys and gals are the ones who know what they are doing;
- the pretend programmers – those are the ones who lack understanding of basic principles, who tinker around for weeks with projects that should take hours, ones who usually master the art of “pretending to be” and are capable of presenting themselves as being highly knowledgeable to an audience that is not capable of probing deeper than the thin layer of knowledge that they have. Those are the fortunate ones who have gotten a “lifetime scholarship” on the IT department of some organization.
After coming up with this classification the answer to my question became crystal clear: the real programmers are significantly underpaid (see the argument below), while the pretend programmers are overpaid. In total as a big group of programmers they are apparently fairly compensated – after all it is the free market that has dictated the levels of compensation we see today.
So why do I think real programmers are underpaid? Well, here is my simple calculation: let’s take an average salary of $80K / year and divide it by 52 weeks that rounds to about $1.5K per week. Now, a real programmer, as I am sure you all know, puts in an average of 60 hours of work per week (not accounting here for the fact that even after those 60 hours he/she is still thinking and reading about how to deal with a challenge, how to more efficiently handle a process etc.) – that translated to a pitiful $25 / hour. Some may disagree with me on the “pitifulness” of the $25 / hour considering that the minimum wage posted on our office hall says $5.85 / hour, but, I can bring plenty of examples to support my statement – examples like my cousin who just started working for a railroad company on the maintenance and makes $27 / hour (mind you no experience and no education) or my next door neighbor (lawyer with experience and education) who won’t start talking for less than $300 / hour. So, where does a real programmer fall in this wide spectrum of abilities and compensations – what I know is that if you consider the intelligence, the education, the sheer amount of work they have put into gaining that education the real programmers are at the top of the spectrum but unfortunately, when it comes to compensation they are between the McDonalds kids flipping burgers and skilled laborers! Sad!
So, what is wrong with this picture and what can one do to correct it? Well, I will leave that for another day – for now, I will go ask for a raise :)
Monday, December 10, 2007
Verbal agreement partnership - bad idea!
Many software businesses nowadays are started as partnerships between 2 or more friends and often, in the interest of simplifying things, the legal entities that are formed do not necessarily match the real agreements between the partners. If you try to dig a bit on the stories, as I have often done, you will find that there is a clear and simple rational for the decisions that have been made during the way - no surprise in that, after all those are very smart people we are talking about and reason is one of their fortes. However, the surprising part is that many of them do not get the real agreement on paper!
Usually the partnership starts with excitement and enthusiasm, a verbal agreement which consists of 20% of explicitly stated terms and 80% of implied or assumed terms, a handshake, and a toast to the success of the new venture!
The beginning is great but conflicts are bound to develop soon thereafter – from vision for the future, to level of commitment of each partner to the venture, down to minute technical details everything presents an “opportunity” for conflict. Partners start developing mistrust for each other and the funny part (not so funny indeed) is that each partner thinks that the others are not living up to the agreement that they made when they started! The root of the trouble as you can imagine is without fail in the implied terms of their verbal agreement – each partner made a different set of assumptions as to what those terms were!
If trouble arises early enough in the process and the partners involved are wise people chances are very good that they will work out the differences and move forward with a clear and written agreement where nothing is implied.
However, oftentimes when the conflict that has been boiling comes in the open it is too late and impossible to settle the differences – some of the partners may end up with the short end of the stick and feel betrayed, friendships are destroyed, and partnership is no more! In short it ends up being an ugly situation (for luck of a stronger word) that you wish you had never been part of!
So how does one avoid getting into such unpleasant situations? Well, here are some simple rules to abide by:
- Never ever enter into a business partnership based on a verbal agreement – handshake is great but paper is much, much better. Don’t feel embarrassed to ask your best friend to get the agreement in writing – you are not showing miss-trust, instead, you are showing that you value the friendship and don’t want to risk it over some business venture.
- Don’t assume anything – write down everything – remember, there is a reason your house insurance policy is 30 pages long (and yet there are still claims that end up in court)! It is not a bad idea to get a lawyer involved to do it right.
- Make sure that both the rights and responsibilities of each partner are clearly spelled out. - Establish clear tie-breakers – “we’ll decide together” does not work – a final authority should be established for each and every type of issue.
- Leave your ego at the door – you are in business to make money not to make a statement. If you want to make a statement go run for an office instead.
- Bring out any reservations you may have as early as possible – those rarely disappear by themselves; instead, the common tendency is for them to grow into big issues if left “un-attended”.
Someone once told me: “I will never get into another partnership again” – I say, partnerships can be great if done right!
Feel free to leave your comments here.
Usually the partnership starts with excitement and enthusiasm, a verbal agreement which consists of 20% of explicitly stated terms and 80% of implied or assumed terms, a handshake, and a toast to the success of the new venture!
The beginning is great but conflicts are bound to develop soon thereafter – from vision for the future, to level of commitment of each partner to the venture, down to minute technical details everything presents an “opportunity” for conflict. Partners start developing mistrust for each other and the funny part (not so funny indeed) is that each partner thinks that the others are not living up to the agreement that they made when they started! The root of the trouble as you can imagine is without fail in the implied terms of their verbal agreement – each partner made a different set of assumptions as to what those terms were!
If trouble arises early enough in the process and the partners involved are wise people chances are very good that they will work out the differences and move forward with a clear and written agreement where nothing is implied.
However, oftentimes when the conflict that has been boiling comes in the open it is too late and impossible to settle the differences – some of the partners may end up with the short end of the stick and feel betrayed, friendships are destroyed, and partnership is no more! In short it ends up being an ugly situation (for luck of a stronger word) that you wish you had never been part of!
So how does one avoid getting into such unpleasant situations? Well, here are some simple rules to abide by:
- Never ever enter into a business partnership based on a verbal agreement – handshake is great but paper is much, much better. Don’t feel embarrassed to ask your best friend to get the agreement in writing – you are not showing miss-trust, instead, you are showing that you value the friendship and don’t want to risk it over some business venture.
- Don’t assume anything – write down everything – remember, there is a reason your house insurance policy is 30 pages long (and yet there are still claims that end up in court)! It is not a bad idea to get a lawyer involved to do it right.
- Make sure that both the rights and responsibilities of each partner are clearly spelled out. - Establish clear tie-breakers – “we’ll decide together” does not work – a final authority should be established for each and every type of issue.
- Leave your ego at the door – you are in business to make money not to make a statement. If you want to make a statement go run for an office instead.
- Bring out any reservations you may have as early as possible – those rarely disappear by themselves; instead, the common tendency is for them to grow into big issues if left “un-attended”.
Someone once told me: “I will never get into another partnership again” – I say, partnerships can be great if done right!
Feel free to leave your comments here.
Time to Give Up!
You are a great software programmer and one morning in the shower an idea hits you – you are all excited. You spend the morning doing some market research and realize that while there are tools out there that resemble your idea none of them does exactly what you want to do. Great!
Countless sleepless nights follow and finally you have a product – you form a company, put up a website and release a public beta. Now you need to let all potential users now of your great creation. After a few days you realize that what you had thought was the easy part is turning out to be the harder one! Messages for products that you believe are inferior to yours seem to be everywhere while your message does not show up anywhere. The prices for advertising seem sky high considering your “budget”. However, with persistence and hard work you manage to round up a few hundred people who download your product.
A month later your tally says that your “baby” is on the hands of over 300 people and when a handful of those start sending you suggestions you are ecstatic and are seriously thinking of quitting your day job. You jump into implementing those suggestions and find yourself spending hours upon hours enhancing your product … this is a critical pitfall that deserves serious consideration but we will leave that discussion for another day so that we don’t divert from the subject of this discussion.
The big day comes, your hard work will finally pay off – version 1 of your product is released! You have managed to collect some hard cash from friends and relatives. You put up your first pay-per-click ads and now can’t wait for your first print ad to appear on that prestigious magazine and your banners to appear on those all popular newsgroups. These are exciting times!
The magazine finally reaches your desk and your confidence shakes a little – your quarter page ad for which you paid dearly seems almost invisible compared to the competitor’s full page. But hey, your product is better then theirs – users will eventually discover that, right?
Days fly by, you keep watching those downloads and wait for the first sale. Finally it comes and it is time for celebration! Now the money from the sales will start feeding the marketing and you can almost feel the g-force of the take off and anticipate the relief you will feel when you will be flying!
A lucky few will actually manage to take off – the evolution of that successful “branch” is outside the scope of this writing – it will be the subject of a future blog entry.
So, let’s go back to the case of the un-lucky many who never manage to take off.
It has been a few months since your first ads appeared and you are disappointed with the results (un-fortunately no one ever told you that a potential customer needs to see your ad about 17 times before being converted into a customer). You can’t afford to get paid help so you start seeking out partners to help you with marketing and further development.
It’s been 6 months – you have spent all the money you borrowed, you have poured every once of your energy juggling between fixing bugs, responding to potential customers and trying to send your message out and you are due for another shock – two of those competitors with inferior products have just released new versions of their software and they are blowing their horns hard. You can’t help notice that they are touting new features that you introduced 6 months ago – it both flatters and angers you! Yes, you are the innovator, they are copying you but unfortunately no one knows that except for them, your competitors.
You don’t have the marketing muscle they have but you can beat them with a superior product so you decide it is time to give it another push to get a new version out there – a version that will outshine theirs and take their customers away…
The more time and energy you pour into this venture the harder and harder it becomes to even consider giving it up. The forgone opportunity cost is huge – should you have accepted that offer to go work for let’s say google when you had just started this you would be a millionaire by now!
So, the question is: how can one tell whether the additional required effort is actually increasing the chances for takeoff OR simply raising the walls of the self-built trap making it ever harder to get out of it? When is it time to give up your dream?
The numerous factors involved make it impossible to come up with a definitive answers – it really depends. But, here are some guidelines to consider – nothing ingenious but helpful guidelines that are often ignored by enthusiastic entrepreneurs:
1. Conduct a financial review every 2 months. Estimate the potential of your product as best you can. Develop three basic scenarios: a best case, great success scenario; a worst case, miserable failure scenario; and a drag along, “midway” scenario. Assign $ potential and probability of happening for each scenario for the next 3 years. Example: successful -> $2M revenue / $500K profit / 20% probability of happening; midway -> $1M revenue / $50K profit / 50% ; failure -> $250K revenue / $200 loss / 30%. If you add the numbers in this example up you will find that you are predicting that you will make a likely profit of $65K for the next 3 years. Is it acceptable considering what you are having to put in? Chances are that when you are just starting you will assign a much higher probability to the success scenario and things will look bright but keep doing this simple exercise and refining those numbers as you gain more experience and deeper knowledge of the market. It is a great exercise that will help wake you up from your dreams and give you a much needed dose of reality.
2. Consider your financial situation periodically and set checkpoints on the way to make sure you are not diving too deep – you need to have enough breath saved to avoid drowning. If you can afford to keep going and you are passionate about what you are doing then by all means keep going, you will find that the numbers (see the paragraph above) after having taken a sharp dive from the early highs will start improving as your product eventually gains acceptance in the market. There is no doubt that good times are ahead if you can persist long enough. You should do this “checking” every two months in conjunction with the checking mentioned above.
3. Carefully monitor what your competitors are doing – if you notice that they are shying away from the products that compete with yours and focusing their efforts on other products it may be that they too are not getting the numbers, so, maybe the demand for your product is just not there.
4. Talk to people who have been successful and ask for their advice – see what they think of your idea. Share the situation with them and ask them pointblank whether they would advice you to give it up or continue pushing it. Many of those successful people have a highly developed sense of when it is time to quit and assuming no conflict of interests are involved their advice is invaluable.
5. And of course, talk to your customers and potential customers as much as you can – ask them what they think of your product; does it provide a good value for them; would they recommend it to someone else, etc. It will give you a fresh perspective and help you focus your efforts on the right areas.
I am sure there are many more checks and indicators that you can, and should consider when deciding to keep going or giving it up. So, please feel free to not only comment on the above suggestions but to list your own suggestions as well. There are many bright programmers with entrepreneurial spirit working on all kings of great products that can be “saved” by a structured, cold hearted approach to evaluating their grandiose ideas.
To all entrepreneurs out there – the biggest favor you can do yourself is to diligently scrutinize your idea periodically to determine whether it is worth to keep investing on it. How you do it, what factors you consider etc. is all up to you and not critically important – making sure you actually do it is what is really important.
Hope this helps many and doesn’t annoy any :)
Friday, December 7, 2007
Don’t do it yourself!
A few years back I met a friend of mine who was in the software components business and while he was explaining to me what his components did I was thinking "who in the World is going to buy those?”, “anyone can now easily do what you are offering with a few lines of code”. However, knowing that my friend was a very smart fellow I gave in, downloaded and reluctantly started using his components here and there in my code. To my surprise it did not take long for me to fall in love with those drag and drop components that took care of setting everything for me.
I started keeping a simple log indicating the minutes I was saving every time I dragged one of those components on my forms. When I wrote 3 minutes on my first log entry a “forget this” thought was floating on the back of my mind but I decided to do it for one whole week…
Have you ever looked doubtfully on a credit card statement where the biggest expense item is $50 and yet somehow the total adds up to $3K! If you have, you understand the doubt I had when those “pitiful” minutes added up to a total of 170!
That was like a wake up call – the proud programmer in me had kept me away from exploring the vast repository of off the shelf components – “I don’t need components, I can do those things myself – not only will my code do the job better but I will have complete control over it and I won’t have to rely on a vendor or another when things don’t work, and besides, I won’t save much time anyway” was my usual reasoning. But, man had I proved myself wrong!
The more I explored the market the stronger became the realization that there are hundreds of extremely intelligent programmers out there pouring their knowledge and energy in creating those incredible, time and frustration saving components but I had “shunned” them – to my own detriment!
Since then I resolved to never ever write a line of code that I don’t have to – I take my time to know and test what’s available out there and I start every project with a list of components and parts that I can use. Nowadays, a much bigger portion of my time is spent in architecting than in bricklaying and it feels good.
A recent meeting with a few bright guys from an IT department prompted me to write this and issue a call to all programmers out there – PLEASE DON’T DO IT YOURSELF if you don’t have to!
PS if you feel the urge to refute this on the grounds that it is better to do it yourself sometimes depending on the situation please don’t waste your time – yes, there are cases when you absolutely must write it yourself but that is not the point here.
I started keeping a simple log indicating the minutes I was saving every time I dragged one of those components on my forms. When I wrote 3 minutes on my first log entry a “forget this” thought was floating on the back of my mind but I decided to do it for one whole week…
Have you ever looked doubtfully on a credit card statement where the biggest expense item is $50 and yet somehow the total adds up to $3K! If you have, you understand the doubt I had when those “pitiful” minutes added up to a total of 170!
That was like a wake up call – the proud programmer in me had kept me away from exploring the vast repository of off the shelf components – “I don’t need components, I can do those things myself – not only will my code do the job better but I will have complete control over it and I won’t have to rely on a vendor or another when things don’t work, and besides, I won’t save much time anyway” was my usual reasoning. But, man had I proved myself wrong!
The more I explored the market the stronger became the realization that there are hundreds of extremely intelligent programmers out there pouring their knowledge and energy in creating those incredible, time and frustration saving components but I had “shunned” them – to my own detriment!
Since then I resolved to never ever write a line of code that I don’t have to – I take my time to know and test what’s available out there and I start every project with a list of components and parts that I can use. Nowadays, a much bigger portion of my time is spent in architecting than in bricklaying and it feels good.
A recent meeting with a few bright guys from an IT department prompted me to write this and issue a call to all programmers out there – PLEASE DON’T DO IT YOURSELF if you don’t have to!
PS if you feel the urge to refute this on the grounds that it is better to do it yourself sometimes depending on the situation please don’t waste your time – yes, there are cases when you absolutely must write it yourself but that is not the point here.
Thursday, December 6, 2007
Why should a .NET/SQL Server developer care about database comparison tools like xSQL Object?
Any .NET developer who has worked with SQL Server has at some point had to deal with the challenge of transferring database changes from the development db to testing or production db. It's always the same, you start your "application enhancement" project with a clear vision of the outcome, you potentially identify the database objects, tables, views, stored procedures, functions etc. that you may have to tweak, completely revamp or build from scratch.
As you move along new changes and additions to the database structure (aka schema) become necessary - you keep making those changes to the database and depending on your type (from highly organized to totally messy), experience (from decades of experience to a rookie programmer) etc. how you handle those changes may vary from the "meticulously document everything" approach to the "I will remember those changes I am making" approach.
While the "document everything" approach is commendable it does unfortunately come with a hefty price tag - a lot of extra hours will be spent on that documentation and to make matters worse no intelligent programmer who gets the adrenaline rush from coming up with ingenious approaches to handling technical challenges enjoys dealing with it.
On the other hand, the "I will remember" approach is not only non-commendable but depending on the complexity and sensitivity of the project it may at times be disastrous - otherwise genius programmers pulling their hair trying to figure out why the application is working fine on their development environment but is going haywire on the production, operations people going nuts over the malfunctioning of the system on which their livelihood depends etc.
So what is an intelligent .NET programmer to do?
Fortunately, there is no need to choose between bad and worst - there is no need to spend all those hours documenting everything (don't take this the wrong way - any good programmer will always take the time to provide sufficient documentation to allow a comparably intelligent human to understand why something was done, who did it and when) nor there is a need to remember what changes you are making. xSQL Object, allows the user to compare two databases and clearly identify all the changes that have been made on the structure (aka schema) of one database versus the other. But wait, it goes way further than that - it allows the
user to generate a safe change script that will apply (transfer) all those changes to the destination database in a single click. Now that's efficiency - something you would have to take hours to do you can handle with xSQL Object in minutes and not only that you can proudly archive the detailed "documentation" of all the changes you made to the database - not only is that commendable but it feels great too - you are doing an outstanding job without having to waste a minute on it.
Here is where things get even better - xSQL Object is completely free, no strings attached, for SQL Server Express edition. And what if I am not using SQL Express but some other edition of SQL Server like the Workgroup Edition, Standard Edition, Enterprise Edition etc? Not to worry, we have thought of that too - xSQL Object is free for those other editions too as long as the number of the objects in your databases is under certain limits.
Subscribe to:
Posts (Atom)