Who says IT is not for non-engineers? Move over IITians, here come the BSc and MSc grads who are developing software for the global market. Technology firms are now hiring non-engineers as well to meet their manpower requirements.
While it costs companies anywhere between Rs 80,000 and a few lakhs to train non-engineers to bring them on par with IIT and regional engineering colleges, the bonus is low attrition rates, availability of a motivated and skilled workforce and lower costs.
27 May, 2006
Top 10 Strangest Gadgets of the Future -via Slashdot
Would you like to start your day by playing games in the urinal or would you like to see the bread changing its color from off-white to golden brown while its being toasted? Gaming consoles are passe, get up and kick your enemy's ass! Checkout the top 10 strangest gadgets of the future... some of the products/concepts are a must see for those who are into interaction design and new media and the like.
Why we all sell code with bugs -Guardian
Why would a company release a product with known bugs? There are several reasons:
. We care about quality so deeply that we know how to decide which bugs are acceptable and which ones are not.
· It is better to ship a product with a known quality level than to ship a product full of surprises.
· The alternative is to fix them and risk introducing worse bugs.
All the reasons are tied up in one truth: every time you fix a bug, you risk introducing another. Every code change is a risk. If you don't recognise this you will never create a shippable product. At some point, you have to decide which bugs aren't going to be fixed.
There are four questions to ask about every bug. The first two are customer ones, and the next two are developer ones.
1) How bad is its impact? (Severity)
2) How often does it happen? (Frequency)
3) How much effort is required to fix it? (Cost)
4) What is the risk of fixing it? (Risk)
. We care about quality so deeply that we know how to decide which bugs are acceptable and which ones are not.
· It is better to ship a product with a known quality level than to ship a product full of surprises.
· The alternative is to fix them and risk introducing worse bugs.
All the reasons are tied up in one truth: every time you fix a bug, you risk introducing another. Every code change is a risk. If you don't recognise this you will never create a shippable product. At some point, you have to decide which bugs aren't going to be fixed.
There are four questions to ask about every bug. The first two are customer ones, and the next two are developer ones.
1) How bad is its impact? (Severity)
2) How often does it happen? (Frequency)
3) How much effort is required to fix it? (Cost)
4) What is the risk of fixing it? (Risk)
Subscribe to:
Posts (Atom)