Here are a few general known statements: success is about passion and motivation. You need to put your heart and efforts into it in order o fully succeed. You cannot take something to the limits if you don’t believe in it and if you are not ready to make some compromises on the way.
Compromise is when you decide for example, for one of the following:
> Career. When you see that investing in one technology / company / team / location / brand / trend… might mean something to you for the future. Might lead you to where you actually want to be, no matter what that is. What mattes is that the compromise you make, the crap you accept for the moment will take you one step closer to your career path. Of course if you have one.
> Money. Usually money does not come on the first place if you are truly honest with yourself. If money comes on the first place when you make a compromise, then yes, you have an income issue that has to be fixed or a planned investment. Otherwise money is a general motivation for a career path. They come either with your skill growth or evolution on the hierarchical scale.
> Environment. Especially in software area environment is key critical to assure an innovative state of mind. Creation and invention is about being open minded, having a friendly environment that welcomes any crazy idea, eventually inspiring crazy new ideas.
> Team. Even if team is part of the environment, I especially named it separately since it has a special influence. Of course you can be a lonely freelancer, but show me a freelancer that is not part of some community. Team, communication, bounding… are all very important even if this is sometime virtual.
> Technology. Again something surprising, something that you might as well consider it as part of the “career” section, but it is not. Don’t full yourself, as much as a guy grows as a manager / career path, he will still stick to one or more technologies and he will still get back to code something. Maybe less, maybe more, but once a developer, always a developer. It is not about what you do, but it is about that satisfaction that you create, that you figure it out by yourself, that you find a fast solution, a better solution.
> Ego. Hmm… what is that? Well it is something that does not eventually translate into 0 or 1, not even in OOP, not a web-service or anything in this area. It is about us humans, being sometimes so proud or so foolishly honest, or anything that has to do only with us. Sometimes ego drives developers (known as having a huge ego) towards decisions and compromises.
> Amount of work, time, exhaustion. This is, of course, part of any job. Within software development, same as other brain efforts, this is important and, depending on the level of it, certain compromises are made. It is very often combined with one of the above. So it usually has a hidden reason. For example you might love a job that allows you to have spare time within working schedule so you can actually focus on studying a technology or on a product or on… making money for other clients, etc.
> Coolness. Yes, this can probable be included in one of the categories above or defined as a certain percent of each of the above combined. Developers have their own world. If you, the one reading my blog, are not part of software world, you would be surprised that we have here our own fashion shows, our trends, our online meetings, our chat, our social networking, our brands, our certifications, etc…
Of course there are other reasons and compromises but I will not get into personal issues such as location or region or economical trends, etc. for the goal of this article we basically stick to the ones above.
So what we learned so far is that a software developer will basically make some compromises and chose his work, keep his work based on the above statements. Sometimes his work and decision is defined by a combination of them, sometimes only by only one direction.
If you as a manager really care about your team and need to keep them motivated, not just working, not just showing up at work, but really impassionate and long term committed (whatever long-term might mean these days for software industry), then you need to know your people. You need to know what drives them. What is the element (for example from the ones above) that really drives the individual?
From my experience a software – related person will be motivated if:
> You, as a manager, make sure you identify and assure a combination of the above
> You, as a manager, make sure you intensify the most important element for each resource.
So far it is all logic and somehow applicable to a range of industries not only software.
If we relate only to software, then I would insist on the ones I mentioned above as special for the industry. You will not find an accountant choosing to work on a specific part of the accounting because of coolness or because of the trend. They will work on it because of the income, because of the market demand for such jobs, because of the general opportunity, because of the corporation brand, etc. They will put passion into it, but they will not chose it because of technology. They will not chose it because of the ego or because it allows them to innovate more.
More than this, software developers tend to become introverts, tend to give up or never grow communication skills, tend to make software their world. Impassionate software developers become their work and behave their work and vice versa: their work will reflect their character and behavior. Sounds freaky or scary? It is so real.
I had friends (yes more than one) that made a mistake when they were tying their shoes and their immediate thought was to do a “Ctrl + Z”. Not laughing? You’re not a developer, then. Oh yeah, there are so many jokes about it, but so many are real. You behave as you think and if you think in algorithms you will behave as such. You will end up planning your life by bubble sort so you organize things fast... Etc..
One of my favorite examples when presenting Software Project Management Tips and Tricks is the one related to shopping list. You may choose a specific methodology (agile, extreme, waterfall, scrum, RUP, etc…) when you do shopping and approach the “cash and carry” shop by using that specific methodology: faster, better, by shelf, by brand, cheaper… depending what you aim.
I can continue but I won’t. I made my case in giving you a glimpse on software developer’s state of mind.
How do you motivate them? Go by their passion.
> By technology – round robin them on technologies (move them from one to another), give them the opportunity to know best one but also constantly get the new ones evaluated.
> By growing their EGO in allowing them to invent and take the credit. Make them special. Make sure the product become their child. Make compromises on decisions when it is THEIR decision.
> By the coolness – stay up with trends and what is cool to learn and put them on that technology / methodology / state of mind /environment. Even if you don’t have the opportunity: invent one. Make all possible compromises that all new requests are going to be built with the “cool” stuff. The results will really make a difference.
> Create the craziest environment. I learned by myself so many times that environment with basically no restriction and actually invitation to wild will not cause you productivity decrease, but even more, will build a team that is productive in spikes but with the average of success and quality clearly above any corporate restrictive environment.
> Select very careful your team. Involve anyone in your choices and never make compromises. Once part of the team and fully accepted, the guy will glow and the team will count on him even if you have some doubts on some of the skills.
> Keep up / high the amount of work. Yes you read it right. A developer with nothing to do will find something to do somewhere else. Keep them very busy and even more, ask extra 3 to 5 cool tasks out of them. Most of us (yeah I am part of it) will go home, do the boring life-related stuff, then switch back to work on the cool tasks.
> Monitor their behavior constantly in order to check all these. Never give up. Not monitoring a resource will lead to loosing it.
> Invent personal projects; encourage them to work on personal ideas for a certain amount of time. Most of them will be useful later. Plan time right and allow them to grow freely their ideas.
> As much as possible make sure money do not become an issue. If handled well all above, money will not become a burning issue. This is of course subject of discussion and economical constraints but I’ve learned that when a developer is reaching to constantly think about money even if YOU DO all that I mentioned above you either are paying him crap or he has issues and you don’t need him.
Is this all? No, there it is so much more in motivating people. This is no general solution, no magic methodology. Really knowing each of your team members and really communicating with them will lead you to so much more thing you can do just to motivate them and keep them focused.
Each one of the above criteria and suggestions can be detailed within a long chapter: environment, ego, money, technology, etc… Maybe I will.
.
Tuesday, May 26, 2009
Saturday, May 23, 2009
Estimating software development is an art (part 1)
Estimating work on software development projects… It seems crystal clear. In fact, what can be so complicated to provide a date and a cost for your project? Every industry requires estimation.
But who estimates? The entire team? Well… yes. But who makes the final decisions? Who provides the required plan and how? How much time can you afford for an estimation? What do you need in order to start estimating? Can you afford not to estimate if you don’t have enough info?
Initially I was puzzled why there was only ONE single person within a 50 members team that was able and entitled and allowed to estimate. Of course everyone within a project team contributed somehow, but the final decision was in on guy’s hand.
We were skilled software developers with some experience, but still, only one of them was estimating and providing a COST and a delivery date for all our products.
After at least 8 years within that company, I become that guy. Without any intention do to that.
I learned by myself, in time, that ESTIMATING IS AN ART. You can’t just do it from the beginning, unless you are incredibly lucky. If you do it, you need to follow the path of an artist. Be original, find your niche, be open minded, etc…
There it is no perfect set of rules to estimate. There are “rules of thumb”, there are “best practices” and there it is “lucky guess”, but there it is no clear process you can follow and provide an accurate estimate. You might find hundreds of estimation methodologies and looking through them you can even find great set of rules and advices. But if you are a new commer, all methodologies are useless since estimation is less than 50% about following a methodology. The rest is inspiration. Inspiration can be a muse or can be an incredible amount of knowledge, twisted and interpreted by your brain.
Within regular processes, it is always someone to suffer: either the provider that estimated waaay to aggressive, or the client that pays waaay too much for the delivered work.
“Time and materials” type of work might work well, but that is a fake, too, since both parties THINK they win, but they might both lose. Usually the client loses a lot of money, paying for his lack of knowledge and incapability to accurately define the problem from the beginning.
“Fixed price” should be the “winning” concept if that fixed price is done right. The “win-win” situation in software is something very hard to achieve.
A combination of fixed price and time and materials might reduce costs, but it is still a compromise accepted because of lack of estimation skills and capacity on any side.
I am starting a set of various articles on this subject: how can you reach to a perfect estimation of time and cost, something that will bring profit to the provider but will not cost enormous the client, something that will allow providers to deliver in time.
My target is not to achieve the perfect win-win scenario but to prepare both software providers and clients on the challenges of this process and also provide some quick tools on how to get closer to the truth, how to check the other party, how to approach the process.
For a start, here are 20 of the most characteristics you have to have if you are a provider estimating a software development project:
1. You have to learn a lot from experience, not from books. Books are good, hopefully this article will contribute, but they mean nothing if you don’t go through real experience since my experience is only good for me no matter how much of it I share: it won’t fit.
2. You have to be impassionate about your work, dedicated. You can’t be accurate if you don’t really put your heart on it. There are so many things you have to count on that it will just feel like giving up and providing some random estimation.
3. You have to be experienced cross-technology. How can you estimate if you didn’t “hit the wall” on s many things before? The estimation final touch is to be made by an expert that can point out risks.
4. You have to have a past position on various layers, from developer to sys architect to DBA to hardware to project management to quality assurance. Business Analysis knowledge is useful, too. You can’t do all. At least, you can’t do all good, just touch some of them. Eventually you can be documented o the rest. You need to know very well the activities you are estimating or count on the experts on each category.
5. You have to really really KNOW your people. Know their skills, know their personal life, know their behavior. It is all about people. Estimation is mainly about people. On guy can do it all in one week, the others can do it in at least a month. I’ve seen it happening.
6. You have to know your business, your managers, your environment. There might be constraints and issues that will increase or reduce the time. A manager that “knows it all” and gets in the way of clean development, might certainly impact the timings.
7. You have to know and follow closely the economical environment your business is running into. This is so obvious, you need to know your rates but also the industry rate and so on. Easy to say but did you ever tried to figure out how much the competition rates are?
8. You have to know your client better then he knows himself. Yeah right. It certainly depends on the client, but it is also achievable since most of the clients might not know their capacity of estimating and evaluation how much are they supposed to pay.
9. You have to know your client’s economical climate and challenges but also success stories. Can your client actually pay? How can you sell your estimate so it gets accepted? What are the milestones dates best fitting your client?
10. You have to be fast, prompt, quick-decision maker, great negotiator. You cannot afford pending too much on items since they will lead the client to doubt your knowledge. You cannot actually “take time for full analysis” there it is no such thing: some things will be figured out as you develop the project, you just need to know where those are.
11. You have to be able to focus and work non-stop for a period of time. Estimation cannot really give you a break. It is an activity with spikes, but it certainly keeps you long nights.
12. You have to be able to parse in a short period of time a very big amount of information, therefore you need to have a great analytic mind. Any estimation starts from an analysis and analysis is usually based on large quantity of information.
13. You have to be able to split this information in modules and tasks. You have to do that fast, while you are accumulating it. The split is not as simple as it sounds since the accuracy of tasks definition and dependency and assignments might influence seriously final estimation.
14. You have to be able to split work in very small elements so that the estimated number of days / hours placed on each will have a maximum of 10% error.
15. You have to be able to guess the unknown. Well, this is impossible right? No. How much do you need to build something that you don’t have ANY idea about. Well… maybe 3 days, maybe a week. If all items above are checked, then you will know that it is 3 days. You will know your buffer. You will ponder your error margin in time.
16. You have to be able to overpass your ego. You have to be flexible and emulate various personalities, ways of thinking, etc.
17. You have to be able to start from 0 and accept that it is all wrong when you are almost done.
18. You have o be able to split information not only by functionality but also by various layers. It is like being able to label information with various labels, then filter it by label. Significant labels.
19. You have to be able to learn from your mistakes. No estimation is perfect but the next one has to be better.
20. You have to be both selective and organized. Selective to identify quick what is important, identify fast patterns, and organized to be able to memorize all the estimates you d and all the mistakes you make… etc…
Is this a super-hero that I am talking about? No. It is just what I describe and every company has one. It is that guy that talks a lot, that guy that knows your birthday, that guy that all clients are talking with, still, it is the developer that thought you the first lessons as part of your induction plan, etc… If a provider does not have someone close to this, then he should look over statistics on estimates and profitability.
Now here’s the funny part: if you don’t have skills like that within your team and you are still a profitable software provider, it means you are darn lucky and you are building a niche product that allows you to just charge a lot. Well, all fine, but I have a question: if you don’t have the estimation guru guy I am talking about,… how do you know you can’t just make even more profit than you already do? :) It might be the case you can charge more but you don’t know. If you would grow this kind of capability within the team, you would know. You would know with a 10% error margin.
Come back soon on the blog for more on this subject. I am working on centralizing rules and best practices for estimation. This is only a light preview on the “Estimation as an art” series of articles. Let’s call it an introduction.
(to be continued)
.
But who estimates? The entire team? Well… yes. But who makes the final decisions? Who provides the required plan and how? How much time can you afford for an estimation? What do you need in order to start estimating? Can you afford not to estimate if you don’t have enough info?
Initially I was puzzled why there was only ONE single person within a 50 members team that was able and entitled and allowed to estimate. Of course everyone within a project team contributed somehow, but the final decision was in on guy’s hand.
We were skilled software developers with some experience, but still, only one of them was estimating and providing a COST and a delivery date for all our products.
After at least 8 years within that company, I become that guy. Without any intention do to that.
I learned by myself, in time, that ESTIMATING IS AN ART. You can’t just do it from the beginning, unless you are incredibly lucky. If you do it, you need to follow the path of an artist. Be original, find your niche, be open minded, etc…
There it is no perfect set of rules to estimate. There are “rules of thumb”, there are “best practices” and there it is “lucky guess”, but there it is no clear process you can follow and provide an accurate estimate. You might find hundreds of estimation methodologies and looking through them you can even find great set of rules and advices. But if you are a new commer, all methodologies are useless since estimation is less than 50% about following a methodology. The rest is inspiration. Inspiration can be a muse or can be an incredible amount of knowledge, twisted and interpreted by your brain.
Within regular processes, it is always someone to suffer: either the provider that estimated waaay to aggressive, or the client that pays waaay too much for the delivered work.
“Time and materials” type of work might work well, but that is a fake, too, since both parties THINK they win, but they might both lose. Usually the client loses a lot of money, paying for his lack of knowledge and incapability to accurately define the problem from the beginning.
“Fixed price” should be the “winning” concept if that fixed price is done right. The “win-win” situation in software is something very hard to achieve.
A combination of fixed price and time and materials might reduce costs, but it is still a compromise accepted because of lack of estimation skills and capacity on any side.
I am starting a set of various articles on this subject: how can you reach to a perfect estimation of time and cost, something that will bring profit to the provider but will not cost enormous the client, something that will allow providers to deliver in time.
My target is not to achieve the perfect win-win scenario but to prepare both software providers and clients on the challenges of this process and also provide some quick tools on how to get closer to the truth, how to check the other party, how to approach the process.
For a start, here are 20 of the most characteristics you have to have if you are a provider estimating a software development project:
1. You have to learn a lot from experience, not from books. Books are good, hopefully this article will contribute, but they mean nothing if you don’t go through real experience since my experience is only good for me no matter how much of it I share: it won’t fit.
2. You have to be impassionate about your work, dedicated. You can’t be accurate if you don’t really put your heart on it. There are so many things you have to count on that it will just feel like giving up and providing some random estimation.
3. You have to be experienced cross-technology. How can you estimate if you didn’t “hit the wall” on s many things before? The estimation final touch is to be made by an expert that can point out risks.
4. You have to have a past position on various layers, from developer to sys architect to DBA to hardware to project management to quality assurance. Business Analysis knowledge is useful, too. You can’t do all. At least, you can’t do all good, just touch some of them. Eventually you can be documented o the rest. You need to know very well the activities you are estimating or count on the experts on each category.
5. You have to really really KNOW your people. Know their skills, know their personal life, know their behavior. It is all about people. Estimation is mainly about people. On guy can do it all in one week, the others can do it in at least a month. I’ve seen it happening.
6. You have to know your business, your managers, your environment. There might be constraints and issues that will increase or reduce the time. A manager that “knows it all” and gets in the way of clean development, might certainly impact the timings.
7. You have to know and follow closely the economical environment your business is running into. This is so obvious, you need to know your rates but also the industry rate and so on. Easy to say but did you ever tried to figure out how much the competition rates are?
8. You have to know your client better then he knows himself. Yeah right. It certainly depends on the client, but it is also achievable since most of the clients might not know their capacity of estimating and evaluation how much are they supposed to pay.
9. You have to know your client’s economical climate and challenges but also success stories. Can your client actually pay? How can you sell your estimate so it gets accepted? What are the milestones dates best fitting your client?
10. You have to be fast, prompt, quick-decision maker, great negotiator. You cannot afford pending too much on items since they will lead the client to doubt your knowledge. You cannot actually “take time for full analysis” there it is no such thing: some things will be figured out as you develop the project, you just need to know where those are.
11. You have to be able to focus and work non-stop for a period of time. Estimation cannot really give you a break. It is an activity with spikes, but it certainly keeps you long nights.
12. You have to be able to parse in a short period of time a very big amount of information, therefore you need to have a great analytic mind. Any estimation starts from an analysis and analysis is usually based on large quantity of information.
13. You have to be able to split this information in modules and tasks. You have to do that fast, while you are accumulating it. The split is not as simple as it sounds since the accuracy of tasks definition and dependency and assignments might influence seriously final estimation.
14. You have to be able to split work in very small elements so that the estimated number of days / hours placed on each will have a maximum of 10% error.
15. You have to be able to guess the unknown. Well, this is impossible right? No. How much do you need to build something that you don’t have ANY idea about. Well… maybe 3 days, maybe a week. If all items above are checked, then you will know that it is 3 days. You will know your buffer. You will ponder your error margin in time.
16. You have to be able to overpass your ego. You have to be flexible and emulate various personalities, ways of thinking, etc.
17. You have to be able to start from 0 and accept that it is all wrong when you are almost done.
18. You have o be able to split information not only by functionality but also by various layers. It is like being able to label information with various labels, then filter it by label. Significant labels.
19. You have to be able to learn from your mistakes. No estimation is perfect but the next one has to be better.
20. You have to be both selective and organized. Selective to identify quick what is important, identify fast patterns, and organized to be able to memorize all the estimates you d and all the mistakes you make… etc…
Is this a super-hero that I am talking about? No. It is just what I describe and every company has one. It is that guy that talks a lot, that guy that knows your birthday, that guy that all clients are talking with, still, it is the developer that thought you the first lessons as part of your induction plan, etc… If a provider does not have someone close to this, then he should look over statistics on estimates and profitability.
Now here’s the funny part: if you don’t have skills like that within your team and you are still a profitable software provider, it means you are darn lucky and you are building a niche product that allows you to just charge a lot. Well, all fine, but I have a question: if you don’t have the estimation guru guy I am talking about,… how do you know you can’t just make even more profit than you already do? :) It might be the case you can charge more but you don’t know. If you would grow this kind of capability within the team, you would know. You would know with a 10% error margin.
Come back soon on the blog for more on this subject. I am working on centralizing rules and best practices for estimation. This is only a light preview on the “Estimation as an art” series of articles. Let’s call it an introduction.
(to be continued)
.
Tuesday, May 12, 2009
World crisis and software development industry
What is going on?
It’s almost impossible not to address this topic. Everybody asks me: what is going on? Where do we go? Not that I know or I am an authority in the field, but because they hope I do same as I hope someone did a brief analysis in this direction. Too much “hope” in the same phrase... Not a good start for an analysis on crysis.
From the first time in IT world the question “where do we go from here” is NOT about technology or methodology.
You might reply by reminding me the crash of “.com” Silicon Valley era when software industry had a serious fall down. Well that was something else: that was the fall of an artificially inflated IT era, when developers and IT corporations were making extraordinary amounts just by knowing something that was not on everybody’s desktop as it is now and just by adding one more on-line shop to the very few existing at that time.
The “.com” era fall was generated mainly by the growth of offer and decrease of needs, it was a natural evolution that usually happens when you have too many offers for the few customers. Other causes were: offshore corporations hitting the market with prices lower by 20 times than US companies, etc... It’s a long discussion, but it all seems now that it happen slowly and natural, following general economical rules as any other business.
Today’s crisis
Today is far more different. Today we do not go through a supply-demand un-balanced situation but we go through a large set of behaviors. The question: “Where do we go from here?” is not only about getting on research and inventing yet another cool thing that will attract customers. It is not only about offshore and outsource. It is not about focusing on higher skilled resources and not even the opposite: lower paid resources. It is a combination of reactions depending on who asks the questions and who responds. It is company’s feeling and reactions, it is company’s skill to adapt to be agile, to survive. There are no general rules or strategies but there are general trends and statistics. “Agile” is the word and we are going straight towards “Extreme”. But it is not even as simple as adapting the “Extreme” word and going with it. I would play now with words and say that you have to be more agile than just applying for “Agile” methodology.
Software industry reactions?
Ok, enough of that.
One of the characteristics of a crisis is that no one knows a darn thing. We all live by statistics. We take decisions based on what is going on around, without forecasting, without planning too much. We react as we feel for the moment, the next moment determining other reactions. Will survive the one who knows how to position himself on the wave, how to twist and turn so his boat does not get smashed.
Is the old story of the boat: you turn your boat based on the wind direction. No, we don’t go with the wind, but you check the wind every second and react every second after. Sometimes against the wind, sometimes with the wind: whatever keeps you alive. You have no idea where you go, you target some location but not really believe you will make it. You try to minimize the wasted time for turning and definitely you try to avoid the wrong direction, but the problem that defines a crisis situation is that you never know the wrong direction: there are no signs for that as in a normal economy is.
I’ve been looking at several IT companies and their behavior during crisis, but after I asked all questions and looked at all factors and reactions, I reached the conclusion that I am looking at the wrong part of the problem. These companies will react based on their clients’ reactions. Software companies are the boat and the Client is the wind. So let’s see how the Client reacts.
I would simply classify their reactions as following:
1. Panic. They just stop everything with no plans or reactions whatsoever. They close all software ongoing contracts, they dismiss their entire IT departments and reduce IT costs to absolute 0 or very close to that. These are usually companies that “can survive” with the software they already have and the loss of IT support is less than painful than losing cash.
2. In-source. They stop all contracts they have externally, they stop buying any software products and they keep a low maintenance in-house with whatever resources they already have. They survive and maintain their software but reducing external costs. This is about companies that need to keep a certain flexibility. This is when the Client realizes that he has to stay agile, has to have a way to adapt, of course about the client that is not yet completely out of financial tools.
3. Extended / planed maintenance. All NEW is stopped and the client will plan, hire, train and adapt it’s internal IT department or even an off-shore small company to maintain and eventually grow / adapt it’s systems. This is about companies that are still moving on the market. They loose, of course, but they can afford to plan for better, they see a need to automate their processes, they see a strong reason to still invest in software (even if reduced) because software will lead to cost decreases eventually.
4. Negotiation. The Client will maintain its’ current investment, but will strongly negotiate all costs and resources involved. They will look at prices, they will perform an extended and annoying control over everything it happens, they will doubt your estimations and they will doubt they need the software, sometimes with suspicion on everything that defines the relation with the software provider. This is about companies that are doing well on the market and want to keep both their growth and their relationship. It is about the Client that still has background energy and is taking the “crisis” as an opportunity to do what he planes to do, but on lower costs and more control. More demanding.
5. Invest. This is the best scenario, when the Client focuses his last breath and last financial tools on technology. It is about the Client that sees software investment as the solution for his escape, for his survival during the crisis. This is planned and targeted, it is the most demanding client, his life might be on software’s provider’s hands, but it can be a win-win situation or a loose-loose situation. It is a gambling.
As you see above, you cannot count on “no reaction”, you cannot count on more cash or positive negotiation. Unless you are lucky or the client in stupid or going to crush eventually anyway.
Everyone reacts and the main characteristic is “reduce costs” even if they would all look into “automate everything and fire everybody”, not everybody can go there.
What is software industry’s response to Client’s reactions.
The main reactions of the IT world are somehow justified by the above categories but not everyone parses the information the same way. Software corporations will:
> Look for more opportunities. They don’t count anymore on “stable” or “solid” contracts. Every potential client is a survival tools for them, even if it is only potential. Marketing suddenly increased.
> Decrease rates. This is natural since rates go with the market, but it is also a survival tool since it leads to code reuse, framework reuse, open source components, software by leasing, etc...
> Merge with other software industries. Sharing clients, reducing redundant costs with staff.
> Increase outsourcing, especially for the ones that tried that before. If they didn’t do outsourcing before now, they rather don’t try now. Not a good moment to setup. Outsourcing is painful at setup and only pays back in time.
> Decrease outsourcing (yes, contradictory with the above) especially if the “production” was done outside and design & analysis done in-side. There is it a trend to keep everything in-house, to reduce external investment, to keep the cash flow for your corporation, country, region...
> Reduce staff. Unfortunately this is a natural measure to be taken when clients go away: they lead to the dismissal of assigned software resources.
> Stop investment in custom development. In times of crisis there are very few to build a software for their business only. Everyone buys off-the-shelf software or invest in maintenance only. Targeting clients for custom development no longer works.
> Expand the targeted clients, extend area. If previously IT companies built very niche and specialized tools, now they have to go with the low prices. To survive out of low prices, you need to target volume, you need to build your products so they get bought by a larger number of clients.
> Recruit only multi-specialized resources, even if with medium skills. Resources ultra specialized on a specific technology are no longer targeted. Of course it is good to have them, but, unfortunately they do not get recruited in times of crisis. You need more of the one-man-show guys.
> Look for cheap solutions. Instead of building things from the ground up, IT companies will look into incorporating already built modules or even take over open-source solutions and extend them. They will look into getting a larger profit margin so less work for same money. This will turn them into integrators, see one of my posts below on one of the most important technology skill these days.
> Focus on services. Investment on long-term products stops or trims, custom development software is reduced, also. You need to review all your clients and see their needs. The client does not want to get rid of you! They want to have you around as much as you do, just that you need to see what are the new type of services (consultancy, integration, open-source configuration) so you survive same as he does.
> ...
Do I consider any conclusion on these above. Yes, a few:
> Wake up. Something is happening and you cannot ignore it.
> Think 3 steps ahead, don’t focus only on ongoing activities
> Be low-priced on your activities. Your client will be, too and you are one of his activities.
> Communicate constantly and keep everyone involved. Generate various partnerships.
> Negotiate everything, revise all deals. Since no one knows the price in times of crisis, the price might mean anything.
> Do not let down quality and services. Instead vary your activity as much as possible.
> Remember, the money are usually THERE. The trust is actually gone. Target the money and keep up the trust.
.
It’s almost impossible not to address this topic. Everybody asks me: what is going on? Where do we go? Not that I know or I am an authority in the field, but because they hope I do same as I hope someone did a brief analysis in this direction. Too much “hope” in the same phrase... Not a good start for an analysis on crysis.
From the first time in IT world the question “where do we go from here” is NOT about technology or methodology.
You might reply by reminding me the crash of “.com” Silicon Valley era when software industry had a serious fall down. Well that was something else: that was the fall of an artificially inflated IT era, when developers and IT corporations were making extraordinary amounts just by knowing something that was not on everybody’s desktop as it is now and just by adding one more on-line shop to the very few existing at that time.
The “.com” era fall was generated mainly by the growth of offer and decrease of needs, it was a natural evolution that usually happens when you have too many offers for the few customers. Other causes were: offshore corporations hitting the market with prices lower by 20 times than US companies, etc... It’s a long discussion, but it all seems now that it happen slowly and natural, following general economical rules as any other business.
Today’s crisis
Today is far more different. Today we do not go through a supply-demand un-balanced situation but we go through a large set of behaviors. The question: “Where do we go from here?” is not only about getting on research and inventing yet another cool thing that will attract customers. It is not only about offshore and outsource. It is not about focusing on higher skilled resources and not even the opposite: lower paid resources. It is a combination of reactions depending on who asks the questions and who responds. It is company’s feeling and reactions, it is company’s skill to adapt to be agile, to survive. There are no general rules or strategies but there are general trends and statistics. “Agile” is the word and we are going straight towards “Extreme”. But it is not even as simple as adapting the “Extreme” word and going with it. I would play now with words and say that you have to be more agile than just applying for “Agile” methodology.
Software industry reactions?
Ok, enough of that.
One of the characteristics of a crisis is that no one knows a darn thing. We all live by statistics. We take decisions based on what is going on around, without forecasting, without planning too much. We react as we feel for the moment, the next moment determining other reactions. Will survive the one who knows how to position himself on the wave, how to twist and turn so his boat does not get smashed.
Is the old story of the boat: you turn your boat based on the wind direction. No, we don’t go with the wind, but you check the wind every second and react every second after. Sometimes against the wind, sometimes with the wind: whatever keeps you alive. You have no idea where you go, you target some location but not really believe you will make it. You try to minimize the wasted time for turning and definitely you try to avoid the wrong direction, but the problem that defines a crisis situation is that you never know the wrong direction: there are no signs for that as in a normal economy is.
I’ve been looking at several IT companies and their behavior during crisis, but after I asked all questions and looked at all factors and reactions, I reached the conclusion that I am looking at the wrong part of the problem. These companies will react based on their clients’ reactions. Software companies are the boat and the Client is the wind. So let’s see how the Client reacts.
I would simply classify their reactions as following:
1. Panic. They just stop everything with no plans or reactions whatsoever. They close all software ongoing contracts, they dismiss their entire IT departments and reduce IT costs to absolute 0 or very close to that. These are usually companies that “can survive” with the software they already have and the loss of IT support is less than painful than losing cash.
2. In-source. They stop all contracts they have externally, they stop buying any software products and they keep a low maintenance in-house with whatever resources they already have. They survive and maintain their software but reducing external costs. This is about companies that need to keep a certain flexibility. This is when the Client realizes that he has to stay agile, has to have a way to adapt, of course about the client that is not yet completely out of financial tools.
3. Extended / planed maintenance. All NEW is stopped and the client will plan, hire, train and adapt it’s internal IT department or even an off-shore small company to maintain and eventually grow / adapt it’s systems. This is about companies that are still moving on the market. They loose, of course, but they can afford to plan for better, they see a need to automate their processes, they see a strong reason to still invest in software (even if reduced) because software will lead to cost decreases eventually.
4. Negotiation. The Client will maintain its’ current investment, but will strongly negotiate all costs and resources involved. They will look at prices, they will perform an extended and annoying control over everything it happens, they will doubt your estimations and they will doubt they need the software, sometimes with suspicion on everything that defines the relation with the software provider. This is about companies that are doing well on the market and want to keep both their growth and their relationship. It is about the Client that still has background energy and is taking the “crisis” as an opportunity to do what he planes to do, but on lower costs and more control. More demanding.
5. Invest. This is the best scenario, when the Client focuses his last breath and last financial tools on technology. It is about the Client that sees software investment as the solution for his escape, for his survival during the crisis. This is planned and targeted, it is the most demanding client, his life might be on software’s provider’s hands, but it can be a win-win situation or a loose-loose situation. It is a gambling.
As you see above, you cannot count on “no reaction”, you cannot count on more cash or positive negotiation. Unless you are lucky or the client in stupid or going to crush eventually anyway.
Everyone reacts and the main characteristic is “reduce costs” even if they would all look into “automate everything and fire everybody”, not everybody can go there.
What is software industry’s response to Client’s reactions.
The main reactions of the IT world are somehow justified by the above categories but not everyone parses the information the same way. Software corporations will:
> Look for more opportunities. They don’t count anymore on “stable” or “solid” contracts. Every potential client is a survival tools for them, even if it is only potential. Marketing suddenly increased.
> Decrease rates. This is natural since rates go with the market, but it is also a survival tool since it leads to code reuse, framework reuse, open source components, software by leasing, etc...
> Merge with other software industries. Sharing clients, reducing redundant costs with staff.
> Increase outsourcing, especially for the ones that tried that before. If they didn’t do outsourcing before now, they rather don’t try now. Not a good moment to setup. Outsourcing is painful at setup and only pays back in time.
> Decrease outsourcing (yes, contradictory with the above) especially if the “production” was done outside and design & analysis done in-side. There is it a trend to keep everything in-house, to reduce external investment, to keep the cash flow for your corporation, country, region...
> Reduce staff. Unfortunately this is a natural measure to be taken when clients go away: they lead to the dismissal of assigned software resources.
> Stop investment in custom development. In times of crisis there are very few to build a software for their business only. Everyone buys off-the-shelf software or invest in maintenance only. Targeting clients for custom development no longer works.
> Expand the targeted clients, extend area. If previously IT companies built very niche and specialized tools, now they have to go with the low prices. To survive out of low prices, you need to target volume, you need to build your products so they get bought by a larger number of clients.
> Recruit only multi-specialized resources, even if with medium skills. Resources ultra specialized on a specific technology are no longer targeted. Of course it is good to have them, but, unfortunately they do not get recruited in times of crisis. You need more of the one-man-show guys.
> Look for cheap solutions. Instead of building things from the ground up, IT companies will look into incorporating already built modules or even take over open-source solutions and extend them. They will look into getting a larger profit margin so less work for same money. This will turn them into integrators, see one of my posts below on one of the most important technology skill these days.
> Focus on services. Investment on long-term products stops or trims, custom development software is reduced, also. You need to review all your clients and see their needs. The client does not want to get rid of you! They want to have you around as much as you do, just that you need to see what are the new type of services (consultancy, integration, open-source configuration) so you survive same as he does.
> ...
Do I consider any conclusion on these above. Yes, a few:
> Wake up. Something is happening and you cannot ignore it.
> Think 3 steps ahead, don’t focus only on ongoing activities
> Be low-priced on your activities. Your client will be, too and you are one of his activities.
> Communicate constantly and keep everyone involved. Generate various partnerships.
> Negotiate everything, revise all deals. Since no one knows the price in times of crisis, the price might mean anything.
> Do not let down quality and services. Instead vary your activity as much as possible.
> Remember, the money are usually THERE. The trust is actually gone. Target the money and keep up the trust.
.
Friday, May 8, 2009
Commenting your code...
Do you work organized? Do you comment your code properly? Well... what does "properly" mean?
Are there any official code commenting standards, something you just take over?
I've been always using something quite plain and clear. My rules of thumb on commenting code are basically:
1. Always comment the complexity! Be generous, it will always turn back on you if you don't.
2. You don't have to comment all methods. It is obvious that the method doSomethingAndReturnAnInt(int intSomeIntVariable) will do something and return an int after using some integer variable. You don't have to just say it. Any comment has to add serious value.
3. Always comment inner loops where you have too many. Of course you rather don't have such things for performance considerations, but when you do, make sure you know what are you looping through.
4. Always use file header generous comments. Who modified what, when? Mark changes on "other people's file" with your name and date of the change and basic reason for changing it. Of course visual source safe does a similar thing but I can afford to have my reasons and still use this rule.
5. Always comment external references. Web Services, external libraries, even references to other modules within your project. A 2nd developer looking at the code can find out everything by looking within same code. Specify what is that and why do you reference that, what are the parameters… etc.
6. Always comment “flags” or defaults or conventions that lead to constants usage in the middle of the code. If you have code like if (x=193) {executeSomeCalculation(intSomeValue)} then you better specify what 193 is. Of course that if you have code like that something is wrong with you, but I rather know what was in your head at that moment then worrying about your development skills.
7. Always comment when you feel like it. When you create something, when you are impassionate, tell the world about it. Document your creation. C’mon, I know you feel like that from time to time. Why do you code otherwise?
8. Always use proper variable and methods naming. This will lead to less need of comments.
9. Always add details for multi-layer applications where you are referencing sql stored procedure. It is very usefull to look in the code and see a method named getSomeDataFomBD(param) that has as comment something like /* will cal stored proc named returnSomeDataFromDB */. It definitelly helps for gebugging.
There are more, but enough of that…
But this is what the priest says not what the priest does :) It doesn’t mean I always do. I always try.
From my experience, coding comments is a matter of corporate culture within software providers. They all start with the basic and adapt to their best practices. Most of them have quite good practices and methodology as reference, but very few apply it right.
If there it is no rule enforced and no strict policies, including the validation after, then no one will do anything.
There are various reasons for adding code comments:
> Because you are very organized and experienced
> Because you are working 12 hours a day on 5 projects and you will forget if you don't add comments
> Because you are working on other developer’s code and you want to make sure you "mark" down your place
> Because you need to impress customer tech representative
> Because you are not sure about what you are doing and you hope someone will eventually have a look at it
> Because you are going to be checked by your boss
> Because the client will check it randomly and you are always lucky
> Because you build custom software but you will probable reach in 4 years from now to maintain it.
> Because you are just thinking you are inventing something cool and the world has to know about it
> ...
Depending on all these above, you might have more or less comments, more or less useful, more or less logic.
There are basic rules that definitely have to be respected. I did not see good commented code too often. I saw "standard" code comments in most of the cases or no comments at all.
I think that standard code comments can be easily removed by having very good and self explanatory variable naming or by having a general organized coding style. What is the need of describing each function name and parameters if you get it from the name. I would love to see code comments that mean something, that describe something interesting, something that will let me understand the complexity by reading it and not invite me to dig a lot in order to fully understand.
I've seen those and they are showing up especially when you put passion on what you're doing, when you feel you invent that thing and you want to come back later or show it off or train someone, etc.
Most of the development shops are actually trying and doing their best with it. As a customer you do not want to hear about it since it seems it will cost you more. You would love it done somehow in the background or, if you buy the final product, you just don’t want it done at all.
As a provider, you add comments when you are going to maintain the thing for years or when you want to live out of the product. And, very important: you pray that the other providers DO add comments for the time you will end up maintaining other guy’s code.
Here's a link that made me laugh a lot. It reflects many of the above by examples from real code comments. It worth reading and please focus especially on the comments on the article, not the article itself. They are hilarious!!!
http://stackoverflow.com/questions/184618?sort=votes&page=1
Other references (please come back with more):
Some basic information here:
http://www.gnu.org/prep/standards/standards.html#Comments
http://www.cs.swan.ac.uk/~csbob/teaching/laramee07commentConvention.pdf
http://www.winnershtriangle.com/w/Articles.XMLCommentsInCSharp.asp
Wiki info:
http://en.wikipedia.org/wiki/Comment_(computer_programming)
ToDo or not ToDo
http://www.approxion.com/?p=39
.
Are there any official code commenting standards, something you just take over?
I've been always using something quite plain and clear. My rules of thumb on commenting code are basically:
1. Always comment the complexity! Be generous, it will always turn back on you if you don't.
2. You don't have to comment all methods. It is obvious that the method doSomethingAndReturnAnInt(int intSomeIntVariable) will do something and return an int after using some integer variable. You don't have to just say it. Any comment has to add serious value.
3. Always comment inner loops where you have too many. Of course you rather don't have such things for performance considerations, but when you do, make sure you know what are you looping through.
4. Always use file header generous comments. Who modified what, when? Mark changes on "other people's file" with your name and date of the change and basic reason for changing it. Of course visual source safe does a similar thing but I can afford to have my reasons and still use this rule.
5. Always comment external references. Web Services, external libraries, even references to other modules within your project. A 2nd developer looking at the code can find out everything by looking within same code. Specify what is that and why do you reference that, what are the parameters… etc.
6. Always comment “flags” or defaults or conventions that lead to constants usage in the middle of the code. If you have code like if (x=193) {executeSomeCalculation(intSomeValue)} then you better specify what 193 is. Of course that if you have code like that something is wrong with you, but I rather know what was in your head at that moment then worrying about your development skills.
7. Always comment when you feel like it. When you create something, when you are impassionate, tell the world about it. Document your creation. C’mon, I know you feel like that from time to time. Why do you code otherwise?
8. Always use proper variable and methods naming. This will lead to less need of comments.
9. Always add details for multi-layer applications where you are referencing sql stored procedure. It is very usefull to look in the code and see a method named getSomeDataFomBD(param) that has as comment something like /* will cal stored proc named returnSomeDataFromDB */. It definitelly helps for gebugging.
There are more, but enough of that…
But this is what the priest says not what the priest does :) It doesn’t mean I always do. I always try.
From my experience, coding comments is a matter of corporate culture within software providers. They all start with the basic and adapt to their best practices. Most of them have quite good practices and methodology as reference, but very few apply it right.
If there it is no rule enforced and no strict policies, including the validation after, then no one will do anything.
There are various reasons for adding code comments:
> Because you are very organized and experienced
> Because you are working 12 hours a day on 5 projects and you will forget if you don't add comments
> Because you are working on other developer’s code and you want to make sure you "mark" down your place
> Because you need to impress customer tech representative
> Because you are not sure about what you are doing and you hope someone will eventually have a look at it
> Because you are going to be checked by your boss
> Because the client will check it randomly and you are always lucky
> Because you build custom software but you will probable reach in 4 years from now to maintain it.
> Because you are just thinking you are inventing something cool and the world has to know about it
> ...
Depending on all these above, you might have more or less comments, more or less useful, more or less logic.
There are basic rules that definitely have to be respected. I did not see good commented code too often. I saw "standard" code comments in most of the cases or no comments at all.
I think that standard code comments can be easily removed by having very good and self explanatory variable naming or by having a general organized coding style. What is the need of describing each function name and parameters if you get it from the name. I would love to see code comments that mean something, that describe something interesting, something that will let me understand the complexity by reading it and not invite me to dig a lot in order to fully understand.
I've seen those and they are showing up especially when you put passion on what you're doing, when you feel you invent that thing and you want to come back later or show it off or train someone, etc.
Most of the development shops are actually trying and doing their best with it. As a customer you do not want to hear about it since it seems it will cost you more. You would love it done somehow in the background or, if you buy the final product, you just don’t want it done at all.
As a provider, you add comments when you are going to maintain the thing for years or when you want to live out of the product. And, very important: you pray that the other providers DO add comments for the time you will end up maintaining other guy’s code.
Here's a link that made me laugh a lot. It reflects many of the above by examples from real code comments. It worth reading and please focus especially on the comments on the article, not the article itself. They are hilarious!!!
http://stackoverflow.com/questions/184618?sort=votes&page=1
Other references (please come back with more):
Some basic information here:
http://www.gnu.org/prep/standards/standards.html#Comments
http://www.cs.swan.ac.uk/~csbob/teaching/laramee07commentConvention.pdf
http://www.winnershtriangle.com/w/Articles.XMLCommentsInCSharp.asp
Wiki info:
http://en.wikipedia.org/wiki/Comment_(computer_programming)
ToDo or not ToDo
http://www.approxion.com/?p=39
.
Saturday, May 2, 2009
What is the most valuable technical skill these days?
I was asked by some good friend that works in IT industry, what is the most valuable technical skill these days... What do IT industry looks for in an employee? What do "Clients" ask for? What is the trend?
You may laugh but, well... If I don't know I search Google, no? Yes I am THAT generation... But the best I can get is this and the last post on it was on 16 Jan 2007. Not even close to acceptable (and I got bored searching quite fast - yes, this is another syndrome of the same Google generation: if I am not lucky, I give up: one-shot-search).
My friend is working in a corporation and he did so for the past 5 years gathering a serious experience in various IT areas. Even more, he comes with another 10 years of previous high technical experience, therefore, the skills he has are quite good. We keep in touch on various matters and this subject came up as a natural one in our discussion. I can fully understand his interest, but, trying to answer I realized there it is NO specific skill I will just mention without having serious doubts right after.
A few things crossed my mind in the first second of articulating an answer: Open Source, SAP, Business Objects, SharePoint, Large Databases analytics, .NET 3.5, PHP, FLASH...
Then I easily reached at "cloud computing" and it's Saas...
But on each one I have serious doubts that that is the "hip". They all seem old to me the second I say them. They seem old and tired. Even the not-released-yet versions are so predictive that they seem old.
Let's see. Back in the days, 12 years ago, the most valuable skill was "OOP". In EU, Delphi was incredible sustained and required by any IT-related industry. Everything that was not FoxPro was Delphi. Some "freaks" were still pushing C++ at that time, but they were just disconsidered by "the clients" and resumed to technical-related activities, educational or very-low level programming.
Then VB came with its soooo easy and simple way of building things. Everything was switched to VB, US made a strong case in there, Office Automation becoming the most desirable skill.
Then Java and shy WEB technologies...
Then pure web, all of it, from HTML to XML to CSS to JS to... JSP, CORBA, MTS, JSF, ....
Then .NET, PHP, MySQL, Databases... AJAX, web 2.0, ...
Then libraries and whatever customizable components and business objects, smart and flexible platforms easy to adapt to "the client's" business or even better: already having the business rules embedded, just select what it is really useful and it is already there.
But that's it... what happen in the last quite short period of time?... It seems that whatever is asked by "the client" already exists. They ask what exists. The sum of their needs is smaller than the sum of all IT systems on the market. The solution is there before the need is there... There are exceptions of course, but this is what happens in general these days. Maybe is the "crisis" but I don't really think so...
So.. what do I answer to my friend?
I think that the most valuable skill these days is to KNOW WHERE TO GET THE SOLUTION FROM. It is already there, you don't need to learn it, you don't need to program it, you don't even need to install it. It is just there. If you KNOW WHERE, then you just get it, link it with various other systems and there you go...
So you need to stay on top of ALL free or commercial, published or announced systems, understand VERY WELL what they do and how do they do, how to link one to another, what protocols. Then meet the client and design the solution. You need to be a well documented integrator. That's it.
I remember the university exams with all books on the table: whatever you might bring, whatever book you think it will help you to solve the problem and even more: internet available on your PC, just USE EVERYTHING available to solve the problem. Who is the student that gets the best reward? The one that:
1. Understands faster the problem, reading through lines, reading the need without even having full specs.
2. Is the fastest to find an existing solution or a group of solutions.
3. Will interpret correctly the search results when he has no experience in that direction
4. Knows exactly how to link the modules, object, platforms..., or even better: did that before.
5. Executes it flawlessly and presents it best.
So those exams were good for something after all... There you go my friend, what else?
.
You may laugh but, well... If I don't know I search Google, no? Yes I am THAT generation... But the best I can get is this and the last post on it was on 16 Jan 2007. Not even close to acceptable (and I got bored searching quite fast - yes, this is another syndrome of the same Google generation: if I am not lucky, I give up: one-shot-search).
My friend is working in a corporation and he did so for the past 5 years gathering a serious experience in various IT areas. Even more, he comes with another 10 years of previous high technical experience, therefore, the skills he has are quite good. We keep in touch on various matters and this subject came up as a natural one in our discussion. I can fully understand his interest, but, trying to answer I realized there it is NO specific skill I will just mention without having serious doubts right after.
A few things crossed my mind in the first second of articulating an answer: Open Source, SAP, Business Objects, SharePoint, Large Databases analytics, .NET 3.5, PHP, FLASH...
Then I easily reached at "cloud computing" and it's Saas...
But on each one I have serious doubts that that is the "hip". They all seem old to me the second I say them. They seem old and tired. Even the not-released-yet versions are so predictive that they seem old.
Let's see. Back in the days, 12 years ago, the most valuable skill was "OOP". In EU, Delphi was incredible sustained and required by any IT-related industry. Everything that was not FoxPro was Delphi. Some "freaks" were still pushing C++ at that time, but they were just disconsidered by "the clients" and resumed to technical-related activities, educational or very-low level programming.
Then VB came with its soooo easy and simple way of building things. Everything was switched to VB, US made a strong case in there, Office Automation becoming the most desirable skill.
Then Java and shy WEB technologies...
Then pure web, all of it, from HTML to XML to CSS to JS to... JSP, CORBA, MTS, JSF, ....
Then .NET, PHP, MySQL, Databases... AJAX, web 2.0, ...
Then libraries and whatever customizable components and business objects, smart and flexible platforms easy to adapt to "the client's" business or even better: already having the business rules embedded, just select what it is really useful and it is already there.
But that's it... what happen in the last quite short period of time?... It seems that whatever is asked by "the client" already exists. They ask what exists. The sum of their needs is smaller than the sum of all IT systems on the market. The solution is there before the need is there... There are exceptions of course, but this is what happens in general these days. Maybe is the "crisis" but I don't really think so...
So.. what do I answer to my friend?
I think that the most valuable skill these days is to KNOW WHERE TO GET THE SOLUTION FROM. It is already there, you don't need to learn it, you don't need to program it, you don't even need to install it. It is just there. If you KNOW WHERE, then you just get it, link it with various other systems and there you go...
So you need to stay on top of ALL free or commercial, published or announced systems, understand VERY WELL what they do and how do they do, how to link one to another, what protocols. Then meet the client and design the solution. You need to be a well documented integrator. That's it.
I remember the university exams with all books on the table: whatever you might bring, whatever book you think it will help you to solve the problem and even more: internet available on your PC, just USE EVERYTHING available to solve the problem. Who is the student that gets the best reward? The one that:
1. Understands faster the problem, reading through lines, reading the need without even having full specs.
2. Is the fastest to find an existing solution or a group of solutions.
3. Will interpret correctly the search results when he has no experience in that direction
4. Knows exactly how to link the modules, object, platforms..., or even better: did that before.
5. Executes it flawlessly and presents it best.
So those exams were good for something after all... There you go my friend, what else?
.
What does come first, the Client or the Project?
"A camel is a horse designed by committee."
Well, this is a version of the same old problem: what does come first? The Client or The Project?
When you work in a Client-oriented scenario you basically cannot say "No" to your client. You may suggest things, you may guide him towards your ideas (if you are good enough in doing that) but if he is stubborn enough, you just can't say "No". In fact... he will pay at the end of it, so it is his decision, as long as he pays your efforts, no matter the service you provide.
But is this really healthy as mentality? What does the Client really want as end result? He wants to solve his problems. He wants a product (or a solution or any service you provide...) that will solve his problem, that will make him happier, that will lead to his growth.
Does he know better than you what is best for him? Maybe not, since he already has the problem he cannot solve. Maybe yes, because he knows better his business, he was already struggling with various solutions and... why not... maybe you are just not the best provider.
My believe is that project comes first, but I tent to believe also that this will happen only in the ideal situation when all parties are looking to understand, are listening and all are looking towards same goal: to find the best solution for the problem, the best idea to fulfill the needs, etc.. not focusing on personal or private, isolated needs.
Usually the Client is focused on suggesting and enforcing solutions that are not always the right ones. Usually the provider is focused on getting the highest profit. Both of the parties meet somewhere in the middle after climbing a mountain of compromises. Then they call this "the project" and start to execute.
There's also the ego. Personal issues since we are all human.
Sometimes the good thing happens. Sometimes you are the right Provider and at the sam time the Client hires you and looks at you as at a specialist, allowing you the freedom you need. Sometimes both of the parties are willing to make all efforts so the project, their "baby" will succeed.
In software development, this (Client enforced solutions vs. proper system design) is a common problem that usually gets self-defined in the beginning of the project. You will see how the project becomes strictly a contractual agreement or becomes something alive, something with a life of it's own, growing...
Is it the same with User-driven development? With online communities and platforms? I think so, yes. You HAVE to listen to your Client, you HAVE to rate your features, but do they always know what is better for them? Not always, (in case of custom software development - not even even frequent).
Does the Provider "surrender" to their Client? Does the Client "surrender" to his Provider? None of the above is right. They both have to "surrender" to the Project... well.. it rarely happens.
Do you surrender to your Client?
Here's the inspirational link of the day:
No! Never Surrender To Your Users, Facebook.
http://www.ngkhai.net/bizdrivenlife/writings/2009/04/13/no-never-surrender-to-your-users-facebook/
Since you are here, read other interesting articles...
The Problem with Problems
""Deficit thinking" sees organizations focusing on what's wrong and problems that need to be solved. In doing so, they often overlook real opportunities"
http://www.ngkhai.net/bizdrivenlife/writings/2009/04/13/the-problem-with-problems/
Why A Blog Can Be Good For Your Business
"You can establish yourself as an expert. Blogs give you a way to reach out to clients..."
http://www.pheedcontent.com/click.phdo?i=e0ee3424bade975c2432439d089de68a
Retaining your best people
"In spite of the obviousness of this crucial responsibility, many organizations suffer from the ‘leaking reservoir’ syndrome"
http://www.codeproject.com/KB/work/Retainingyourbestpeople.aspx
.
Well, this is a version of the same old problem: what does come first? The Client or The Project?
When you work in a Client-oriented scenario you basically cannot say "No" to your client. You may suggest things, you may guide him towards your ideas (if you are good enough in doing that) but if he is stubborn enough, you just can't say "No". In fact... he will pay at the end of it, so it is his decision, as long as he pays your efforts, no matter the service you provide.
But is this really healthy as mentality? What does the Client really want as end result? He wants to solve his problems. He wants a product (or a solution or any service you provide...) that will solve his problem, that will make him happier, that will lead to his growth.
Does he know better than you what is best for him? Maybe not, since he already has the problem he cannot solve. Maybe yes, because he knows better his business, he was already struggling with various solutions and... why not... maybe you are just not the best provider.
My believe is that project comes first, but I tent to believe also that this will happen only in the ideal situation when all parties are looking to understand, are listening and all are looking towards same goal: to find the best solution for the problem, the best idea to fulfill the needs, etc.. not focusing on personal or private, isolated needs.
Usually the Client is focused on suggesting and enforcing solutions that are not always the right ones. Usually the provider is focused on getting the highest profit. Both of the parties meet somewhere in the middle after climbing a mountain of compromises. Then they call this "the project" and start to execute.
There's also the ego. Personal issues since we are all human.
Sometimes the good thing happens. Sometimes you are the right Provider and at the sam time the Client hires you and looks at you as at a specialist, allowing you the freedom you need. Sometimes both of the parties are willing to make all efforts so the project, their "baby" will succeed.
In software development, this (Client enforced solutions vs. proper system design) is a common problem that usually gets self-defined in the beginning of the project. You will see how the project becomes strictly a contractual agreement or becomes something alive, something with a life of it's own, growing...
Is it the same with User-driven development? With online communities and platforms? I think so, yes. You HAVE to listen to your Client, you HAVE to rate your features, but do they always know what is better for them? Not always, (in case of custom software development - not even even frequent).
Does the Provider "surrender" to their Client? Does the Client "surrender" to his Provider? None of the above is right. They both have to "surrender" to the Project... well.. it rarely happens.
Do you surrender to your Client?
Here's the inspirational link of the day:
No! Never Surrender To Your Users, Facebook.
http://www.ngkhai.net/bizdrivenlife/writings/2009/04/13/no-never-surrender-to-your-users-facebook/
Since you are here, read other interesting articles...
The Problem with Problems
""Deficit thinking" sees organizations focusing on what's wrong and problems that need to be solved. In doing so, they often overlook real opportunities"
http://www.ngkhai.net/bizdrivenlife/writings/2009/04/13/the-problem-with-problems/
Why A Blog Can Be Good For Your Business
"You can establish yourself as an expert. Blogs give you a way to reach out to clients..."
http://www.pheedcontent.com/click.phdo?i=e0ee3424bade975c2432439d089de68a
Retaining your best people
"In spite of the obviousness of this crucial responsibility, many organizations suffer from the ‘leaking reservoir’ syndrome"
http://www.codeproject.com/KB/work/Retainingyourbestpeople.aspx
.
Subscribe to:
Posts (Atom)
Posts
