I doubt if many of us would be as productive if we did not google. Google is a secondary/tertiary store of information for most professionals. A good "primary" memory is an advantage, but not in the way it was in pre-Google days.
The other day I was speaking with a young friend. He works for a well known software MNC. He mentioned that in an interview that he had conducted, the candidate had responded to a question by saying that he could get the information by googling. The candidate failed.
I have been thinking about that. If the candidate failed because of his dependence on Google, it was a mistake. I think he should have been allowed access to the Internet to get the information. After that the interview should have been about ability to process the information in a job related situation.
In college, machine design exams were open-book exams. With Google being available ubiquitously, there is no reason the job interviews too should not be "open-book".
29 October 2010
Culture First
I posted yesterday about PSL, a software services company in Latin America.
They first got the culture of process driven software development firmly in place, before they decided to grow. If they had not done that quality would not have been sustained.
They first got the culture of process driven software development firmly in place, before they decided to grow. If they had not done that quality would not have been sustained.
28 October 2010
Lessons from a Software Company in Columbia
Do you know what are CIVETS? I knew they were a type of cat but I did not know that the acronym stands for Columbia, Indonesia, Vietnam, Egypt, Turkey, South Africa. Incidentally South Africa also occurs in BRICS.
Watch this webinar about PSL, a small software company in Columbia. I thought Columbia was synonymous with drug cartels. Hardly the place for software companies. The webinar was an eye-opener.
Marketing of Services. Sometime in 2007 I realized that we were not marketing acmet's Tools BU correctly. Acmet's marketing talked of all the products that we had made for others. There was nothing about our people and our processes. I came to realize that we had to put our developers, the people who lived the process, right in front where prospective customers could talk to them. We had to display aretfacts of our process as part of sales talk. Unfortunately, it was too late. Nonetheless, it is gratifying that the webinar validates the approach.
Watch the video on PSL's site. Hear why Latin Americans have an advantage over Asians (read Indians) :-)
Watch this webinar about PSL, a small software company in Columbia. I thought Columbia was synonymous with drug cartels. Hardly the place for software companies. The webinar was an eye-opener.
Marketing of Services. Sometime in 2007 I realized that we were not marketing acmet's Tools BU correctly. Acmet's marketing talked of all the products that we had made for others. There was nothing about our people and our processes. I came to realize that we had to put our developers, the people who lived the process, right in front where prospective customers could talk to them. We had to display aretfacts of our process as part of sales talk. Unfortunately, it was too late. Nonetheless, it is gratifying that the webinar validates the approach.
Watch the video on PSL's site. Hear why Latin Americans have an advantage over Asians (read Indians) :-)
Code Comments, Process Worth
Yesterday I was leafing through Guy Kawasaki's, "Reality Check". I had read it a year ago. There were many statements that resonated with me. Here are two of them.
Code Comments
"Luckily the lack of comments usually doesn't matter, because the code is so crappy that a total rewrite is necessary in year."
Lack of comments is a bad smell.
Process
Quoting Stanford psychology profesor Carol Dweck, Guy says, "Instead of praising children's intelligence or talent, focus on the processes they used."
And at the end of the chapter: " ... focus on the process worth ethic, not the inherent brilliance, of your employees."
At acmet's Tools BU we certainly did that.
Code Comments
"Luckily the lack of comments usually doesn't matter, because the code is so crappy that a total rewrite is necessary in year."
Lack of comments is a bad smell.
Process
Quoting Stanford psychology profesor Carol Dweck, Guy says, "Instead of praising children's intelligence or talent, focus on the processes they used."
And at the end of the chapter: " ... focus on the process worth ethic, not the inherent brilliance, of your employees."
At acmet's Tools BU we certainly did that.
25 October 2010
Innovation: Staffing
Govindarajan & Trimble , as mentioned in an earlier post, describe the Performance Engine and the Dedicated Team and why they should be distinct. The book also mentions the need to have a proper relationship between the two so that the resources, skills and knowledge of the Performance Engine can be effectively leveraged.
Context To Core
Geoffrey Moore, in his book Dealing with Darwin: How Great Companies Innovate at Every Phase of Their Evolution, speaks of the need to allocate from Context to Core. Context consists of whatever the company needs to do to stay in the game. Core is what the company needs to do to stay ahead in the game - and that is innovate. (Watch video of Geoffrey Moore on Context and Core in the Software Industry). However, Geoffrey Moore does not deal with the barriers to allocating from Context to Core and how to overcome them. Govindarajan & Trimble do that.
Moonlighting
Givindarajan & Trimble advise against trying to do worthwhile innovation with people working in their slack time. It is not as if such "moonlighting" cannot come up with ideas or small victories, or incremental improvements. What they fail at is, in the words of the book's title, "the other side of Innovation".
Concerning Startups: There are startups where the "entrepreneurs" are not entrepreneurial enough to quit their regular jobs. Such a startup is is not a place to be employed; nor are these people to be doing business with. At acmet we dealt with one such firm.
Missing Performance Engine
I mentioned in an earlier post that a startup, unlike an established organizatiion, has a Dedicated Team with no associated Performance Engine. It has its advantages; it is not burdened by the past. But that is also a disadvantage. The startup does not have a brand. It does not have a set of customers who trust it.
Mitigation: These diadvantages can be mitigated, to an extent, if the entrepreneurs have worked in the industry in various roles - production, product development, marketing & sales. They should be known within the industry and to customers who use the products and services of the industry.
When RR & I started Ergo Electronics we lacked this. We could have overcome this disadvantage. I suppose hubris prevented us, both then, and later at acmet, from never really being able to so.
Postscript
With this post I have ended my current set of takes on Govindrajan & Trimble's book.
If you work at an established company, the book will help you understand what your company needs to do if wants to innovate. Maybe you could suggest what needs to be done, and why.
If you intend to start a venture, or are already in one, I hope my posts would have motivated you to read the book.
Thank you for your attention.
Context To Core
Geoffrey Moore, in his book Dealing with Darwin: How Great Companies Innovate at Every Phase of Their Evolution, speaks of the need to allocate from Context to Core. Context consists of whatever the company needs to do to stay in the game. Core is what the company needs to do to stay ahead in the game - and that is innovate. (Watch video of Geoffrey Moore on Context and Core in the Software Industry). However, Geoffrey Moore does not deal with the barriers to allocating from Context to Core and how to overcome them. Govindarajan & Trimble do that.
Moonlighting
Givindarajan & Trimble advise against trying to do worthwhile innovation with people working in their slack time. It is not as if such "moonlighting" cannot come up with ideas or small victories, or incremental improvements. What they fail at is, in the words of the book's title, "the other side of Innovation".
Concerning Startups: There are startups where the "entrepreneurs" are not entrepreneurial enough to quit their regular jobs. Such a startup is is not a place to be employed; nor are these people to be doing business with. At acmet we dealt with one such firm.
Missing Performance Engine
I mentioned in an earlier post that a startup, unlike an established organizatiion, has a Dedicated Team with no associated Performance Engine. It has its advantages; it is not burdened by the past. But that is also a disadvantage. The startup does not have a brand. It does not have a set of customers who trust it.
Mitigation: These diadvantages can be mitigated, to an extent, if the entrepreneurs have worked in the industry in various roles - production, product development, marketing & sales. They should be known within the industry and to customers who use the products and services of the industry.
When RR & I started Ergo Electronics we lacked this. We could have overcome this disadvantage. I suppose hubris prevented us, both then, and later at acmet, from never really being able to so.
Postscript
With this post I have ended my current set of takes on Govindrajan & Trimble's book.
If you work at an established company, the book will help you understand what your company needs to do if wants to innovate. Maybe you could suggest what needs to be done, and why.
If you intend to start a venture, or are already in one, I hope my posts would have motivated you to read the book.
Thank you for your attention.
24 October 2010
Innovation: The acmet Tools BU Experience
In my last post I mentioned the estimation funnel. The funnel is caused by the non-routine nature of any innovation initiative. Any software work, which is non-routine for the organization, is subject to the estimation funnel (see slide 2 of this document). It is an innovation initiative.
At acmet's tools BU, for the maintenance work that we did on our compilers, we could, with a fair degree of accuracy, estimate and commit to targets. These were routine. We did, on the other hand, construct a dsp compiler, an assembler, a linker, an elf to IEEE695 format converter, an assembly to assembly converter. These were innovation initiatives for us.
Govindarajan & Trimble list 10 principles to formalize experiments. One of them is: Find ways to spend a little, learn a lot. They characterize unknowns along two axes - consequence of being wrong, extent of ignorance. The ones with the most serious consequences and with the highest degree of ignorance are the ones that are most critical. These should be resolved first. That is precisely what protyping and incremental development is about. The authors give the example of how IBM used prototyping to for the development of the Blue Gene supercomputer.
Tools BU Experience
Initially, we made commitments to the customer that we failed to keep. We learned. We learned to develop incrementally. We learned to prototype. We learned to do the learning as an in-house project and not subject ourselves to pressures caused by schedules based on pure guesswork. Of course in-house projects have a perception problem.
At the time acmet decided to close operations, the tools BU was working on porting the GCC to a VLIW DSP. This was, for us, the most innovative. And we did go about setting up experiments to resolve unknowns. The project had as its first target, a prototype that would generate code for an FIR routine. The target was to match the performance of hand coded assembly. Most importantly, though we had a prospective customer, I refused to commit to firm dates. I admitted that all I had were guesses, not estimates. At the time I did not know it, but what we were really engaged in was a rigorous learning process.
At acmet's tools BU, for the maintenance work that we did on our compilers, we could, with a fair degree of accuracy, estimate and commit to targets. These were routine. We did, on the other hand, construct a dsp compiler, an assembler, a linker, an elf to IEEE695 format converter, an assembly to assembly converter. These were innovation initiatives for us.
Govindarajan & Trimble list 10 principles to formalize experiments. One of them is: Find ways to spend a little, learn a lot. They characterize unknowns along two axes - consequence of being wrong, extent of ignorance. The ones with the most serious consequences and with the highest degree of ignorance are the ones that are most critical. These should be resolved first. That is precisely what protyping and incremental development is about. The authors give the example of how IBM used prototyping to for the development of the Blue Gene supercomputer.
Tools BU Experience
Initially, we made commitments to the customer that we failed to keep. We learned. We learned to develop incrementally. We learned to prototype. We learned to do the learning as an in-house project and not subject ourselves to pressures caused by schedules based on pure guesswork. Of course in-house projects have a perception problem.
At the time acmet decided to close operations, the tools BU was working on porting the GCC to a VLIW DSP. This was, for us, the most innovative. And we did go about setting up experiments to resolve unknowns. The project had as its first target, a prototype that would generate code for an FIR routine. The target was to match the performance of hand coded assembly. Most importantly, though we had a prospective customer, I refused to commit to firm dates. I admitted that all I had were guesses, not estimates. At the time I did not know it, but what we were really engaged in was a rigorous learning process.
23 October 2010
Innovation: Established Organizations & Startups - Learning Process
In my earlier post I mentioned that Govindarajan & Trimble describe a rigorous learning process.
The effect of a rigorous learning process is that estimates become progressively more accurate over time. They illustrate it with a diagram. The diagram is precisely what softwarewallahs call "The Estimation Funnel"! (See my post on Estimation).
Estimates are based on hypotheses about cause and effect; they are of the form if < action.> then <result>. Hypotheses, as in the scientific method, must be tested by experimentation. Evaluation of results must be free of biases (the authors describe these biases). Adhering to the sceintific method is what makes the learning process rigorous.
The genesis of all startups too are a set of hypotheses. These concern pain points, market size, value provided, revenue streams, costs, ... All of that goes into the business plan. The business plan is a set of hypotheses about business reality. It is not business reality. The rigorous learning method is required to evolve the business plan to conform more closely to reality.
The authors provide a simple graphical tool for recording the hypotheses. They call it a "hypothesis of record". They illustrate it with an example of how Analog Devices actually put it to use.
Further, the acts of making the business/innovation plan and rigorous learning cover, in my opinion, the first three steps of the Shewhart PDCA cycle. Not surprising, as continuous quality improvement too is based on hypotheses.
The effect of a rigorous learning process is that estimates become progressively more accurate over time. They illustrate it with a diagram. The diagram is precisely what softwarewallahs call "The Estimation Funnel"! (See my post on Estimation).
Estimates are based on hypotheses about cause and effect; they are of the form if < action.> then <result>
The genesis of all startups too are a set of hypotheses. These concern pain points, market size, value provided, revenue streams, costs, ... All of that goes into the business plan. The business plan is a set of hypotheses about business reality. It is not business reality. The rigorous learning method is required to evolve the business plan to conform more closely to reality.
The authors provide a simple graphical tool for recording the hypotheses. They call it a "hypothesis of record". They illustrate it with an example of how Analog Devices actually put it to use.
Further, the acts of making the business/innovation plan and rigorous learning cover, in my opinion, the first three steps of the Shewhart PDCA cycle. Not surprising, as continuous quality improvement too is based on hypotheses.
22 October 2010
Innovation: Established Companies & Start-ups - The Business Plan
In continuation of my earlier post.
Quote from Govindrajan & Tremble's book:
"Given the uncertainities involved, writing an innovation plan can feel like writing a work of fiction. The predictions in them are wild guesses. Indeed in many cases, those trying to sell the intiatiative have deliberately stretched the projections to make the return on investment look better".
That is pretty much applicable to business plans made by start-ups. So what is the value of a business/innovation plan? The authors say:
"The value of an innovation plan is that it serves as a benchmark for subsequent learning." (Emphasis is mine).
By learning, the authors do not mean some academic, ivory tower stuff. They define, what they call a "rigorous learning process". Start-ups too should adopt the same process. I shall talk about it in my next post.
Quote from Govindrajan & Tremble's book:
"Given the uncertainities involved, writing an innovation plan can feel like writing a work of fiction. The predictions in them are wild guesses. Indeed in many cases, those trying to sell the intiatiative have deliberately stretched the projections to make the return on investment look better".
That is pretty much applicable to business plans made by start-ups. So what is the value of a business/innovation plan? The authors say:
"The value of an innovation plan is that it serves as a benchmark for subsequent learning." (Emphasis is mine).
By learning, the authors do not mean some academic, ivory tower stuff. They define, what they call a "rigorous learning process". Start-ups too should adopt the same process. I shall talk about it in my next post.
20 October 2010
Innovation: Established Organizations & Start-ups
Vijay Govindrajan & Chris Trimble's book on Innovation is about innovation at established companies. The book explains why established organizations find innovation difficult and offers them a prescription. Nevertheless, I think the book is essential reading for persons running start-ups and small companies. What follows, in this and a few subsequent posts are my take-aways from the book.
Innovation consists of two parts - the idea and then its implementation. Ideas are the easy part. It is in successfully implementing ideas that established companies falter. The reason is that established companies evolve for efficiency. The authors call them Performance Engines. Performance Engines value predictability, small variance, and meeting targets. Performance Engines have past data . Innovation implementation have no past data for making forecasts. The authors state bluntly, "The first rule of innovation is simple: Innovation and on-going operations are always and inevitably in conflict" (italics are the authors'). Therefore, the team responsible for implementing the innovation must be distinct from the Performance Engine. "Each innovation initiative requires a team with a custom organizational model and a plan that is revised only through a rigorous learning process" (emphasis is mine). They name such a team as the Dedicated Team. It is good partnership between the Dedicated Team and the Performance Engine that leads to successful innovation by established companies.
The way I see it, all start-ups, and small companies, are Dedicated Teams without an associated Performace Engine. Thus, what the authors have to say about the Dedicated Team, apart from the relationship with a Performance Engine, is of value to start-ups. I will post on some of these in following posts
Innovation consists of two parts - the idea and then its implementation. Ideas are the easy part. It is in successfully implementing ideas that established companies falter. The reason is that established companies evolve for efficiency. The authors call them Performance Engines. Performance Engines value predictability, small variance, and meeting targets. Performance Engines have past data . Innovation implementation have no past data for making forecasts. The authors state bluntly, "The first rule of innovation is simple: Innovation and on-going operations are always and inevitably in conflict" (italics are the authors'). Therefore, the team responsible for implementing the innovation must be distinct from the Performance Engine. "Each innovation initiative requires a team with a custom organizational model and a plan that is revised only through a rigorous learning process" (emphasis is mine). They name such a team as the Dedicated Team. It is good partnership between the Dedicated Team and the Performance Engine that leads to successful innovation by established companies.
The way I see it, all start-ups, and small companies, are Dedicated Teams without an associated Performace Engine. Thus, what the authors have to say about the Dedicated Team, apart from the relationship with a Performance Engine, is of value to start-ups. I will post on some of these in following posts
Innovation: Skunk Works
The problem with having hackers is that most are pretenders. As Paul Graham says, "This attitude is sometimes affected. Sometimes young programmers notice the eccentricities of eminent hackers and decide to adopt some of their own in order to seem smarter. The fake version is not merely annoying; the prickly attitude of these posers can actually slow the process of innovation." So what do you do with the pretenders? Obviously they must be got rid of. Who best to do it than the real hackers. In a company that is no longer a startup that would be problematic. I think one solution is to have a something on the lines of Lockheed's legendary Skunk Works, where innovative, and highly successful, aircraft like the U-2, the SR-71, and the Stealth fighter were created.
Skunk works need to be separated from the normal, on going, revenue generating, business. It needs to be run with different policies and controls for personnel, finance and administration. Skunk Works: A Personal Memoir of My Years of Lockheed gives some idea of how a skunk works is run
.Problem for Small Software Companies
At acmet's Tools BU the GCC port was, in some ways, a skunk works operation.Some of the people on customer-billed projects regarded it as a glorfied on-bench tenure. Some of the people on the project - some time or the other - also felt that they were on-bench. This, I feel, would happen in most small software companies. It is the job of the senior manager, responsible for the skunk work project, to counter such perceptions.
Clarification
Innovation does not mean invention. A number of people may have done it before, but if for us it is new, then we are being innovative. The innovation need not necessarily lie only in the product. It can lie in the process, or the services bundled with the product. The GCC port work had never been done by us before. It was going to be a new business model for us. For acmet's tools BU it was innovative.
19 October 2010
Estimation
Interesting set of slides on Estimation.
Slide 2: Is the estimation "funnel"
Slide 11: acmet's tools BU fell in the Nominal category.
Slide 14: For 10K lines (I do not know how these are defined - whether they include data definitions, unit tests, documentation, ...) 10 calendar months and 48 (say 50) staff-months. That is 10 lines/day ((10K/50 staff-months)/20 days/staff-month). That is somewhere near the figure that we got. Also, no mention is made of the expected residual defects.
I have a thumb rule: The number of residual defects per 1K XTSLN equals the effective XTSLN/staff-day over the elapsed time. At 10 XTSLN I would expect about 10 defects/1K XTSLN. Of course to get 0 defects/1KXTSLN we would be coding at an effective rate of 0 XTSLN/staff-day. That is not as odd as it may sound. To reduce to zero defects one would require infinite time.
(Note: XTSLN is a Lines of Code metric defined and measured by the QA C tool)
Slide 18: This is my favourite. It illustrates the estimation funnel. Note
the relative error column. There is not even 1 negative entry! For a 5 year
project the estimate becomes accurate 3 months prior to ship.
Slide 22: Note the last bullet.
Slide 23: **** Worth remembering *****
Slide 26: These are all the recovery techniques.
Note: Praying is *** not *** a recovery technique.
Slide 2: Is the estimation "funnel"
Slide 11: acmet's tools BU fell in the Nominal category.
Slide 14: For 10K lines (I do not know how these are defined - whether they include data definitions, unit tests, documentation, ...) 10 calendar months and 48 (say 50) staff-months. That is 10 lines/day ((10K/50 staff-months)/20 days/staff-month). That is somewhere near the figure that we got. Also, no mention is made of the expected residual defects.
I have a thumb rule: The number of residual defects per 1K XTSLN equals the effective XTSLN/staff-day over the elapsed time. At 10 XTSLN I would expect about 10 defects/1K XTSLN. Of course to get 0 defects/1KXTSLN we would be coding at an effective rate of 0 XTSLN/staff-day. That is not as odd as it may sound. To reduce to zero defects one would require infinite time.
(Note: XTSLN is a Lines of Code metric defined and measured by the QA C tool)
Slide 18: This is my favourite. It illustrates the estimation funnel. Note
the relative error column. There is not even 1 negative entry! For a 5 year
project the estimate becomes accurate 3 months prior to ship.
Slide 22: Note the last bullet.
Slide 23: **** Worth remembering *****
Slide 26: These are all the recovery techniques.
Note: Praying is *** not *** a recovery technique.
18 October 2010
CWG: Time To Do The Hansei
The Commonwealth Games by all accounts went off well. That it was headed for a disaster will soon be forgotten. If we do get the 2020 Olympics there is every likelihood that we will again prepare for it in the same manner.
A large complex project, involving multiple government agencies, with no option of slippage requires a highly skilled and motivated management team. And since the national image is involved, the team must have access to, and the whole-hearted support of, the highest rungs of the political leadership. Suitable talent should be shortlisted. The UID project, headed by Nandan Nilekani, brought in with the status of a Minister of State in the Union cabinet, should be the model.
Based on the current experience, we need to create a project plan - complete wih check lists (e.g. signs near building housing the ozzie team saying,"Beware of Falling Refrigerators:-). The project plan must be periodically reviewed and updated since financial conditions, technology, security environment, facilty benchmarks, vendors, ,, all will change. The sports ministry should do this, if we are serious about conducting the 2020 Olympics.
Holding enquiries into alleged siphoning of funds, punishing the guilty, assuming any are found, is all very well, but it will not reduce the chances a repetition.
For that we need to do the Hansei.
A large complex project, involving multiple government agencies, with no option of slippage requires a highly skilled and motivated management team. And since the national image is involved, the team must have access to, and the whole-hearted support of, the highest rungs of the political leadership. Suitable talent should be shortlisted. The UID project, headed by Nandan Nilekani, brought in with the status of a Minister of State in the Union cabinet, should be the model.
Based on the current experience, we need to create a project plan - complete wih check lists (e.g. signs near building housing the ozzie team saying,"Beware of Falling Refrigerators:-). The project plan must be periodically reviewed and updated since financial conditions, technology, security environment, facilty benchmarks, vendors, ,, all will change. The sports ministry should do this, if we are serious about conducting the 2020 Olympics.
Holding enquiries into alleged siphoning of funds, punishing the guilty, assuming any are found, is all very well, but it will not reduce the chances a repetition.
For that we need to do the Hansei.
16 October 2010
Rituals
Today is Ayudha Puja.
My father, sometime after he past 70 years, gave up driving. He then employed a driver. My father continued to regularly check the battery water, the radiator water, tyre pressure. He would ensure that the car went for its regular monthly servicing. On Ayudha puja he did not apply sandalwood paste to the car, nor bedeck it with flowers. The drivers would do that.
I like to think my father performed the puja that was required. Rituals must be appropriate.
Software processes too are rituals. They are rituals which provide the assuarnce that your software does what it is meant to do. They are rituals that have to be performed continuously, and concurrently with writing the code. Applying sandalwood paste, turmeric, and burning incense will do nothing for the code (nor for your keyboard, nor your display).
Greetings for Dussehra: May you never let the demons get into your code. If they do, then may you always slay them at the earliest.
My father, sometime after he past 70 years, gave up driving. He then employed a driver. My father continued to regularly check the battery water, the radiator water, tyre pressure. He would ensure that the car went for its regular monthly servicing. On Ayudha puja he did not apply sandalwood paste to the car, nor bedeck it with flowers. The drivers would do that.
I like to think my father performed the puja that was required. Rituals must be appropriate.
Software processes too are rituals. They are rituals which provide the assuarnce that your software does what it is meant to do. They are rituals that have to be performed continuously, and concurrently with writing the code. Applying sandalwood paste, turmeric, and burning incense will do nothing for the code (nor for your keyboard, nor your display).
Greetings for Dussehra: May you never let the demons get into your code. If they do, then may you always slay them at the earliest.
15 October 2010
Do Not Emulate Dronacharya
The national award for sports coaches is the Dronacharya award.
Dronacharya played politics. First he would not accept Eklavya as his students on grounds of race. Next when Eklavaya coached himself and became better than his star pupil, Arjun, Dronacharya managed to ensure that Eklavaya would not be the best archer of his time.
If Indian coaches play favourites, why blame them. They are emulating Dronacharya.
Lesson for Software Coaches: Do not play favourites.Nurture talent without any heed to caste, or creed, or region.
Dronacharya played politics. First he would not accept Eklavya as his students on grounds of race. Next when Eklavaya coached himself and became better than his star pupil, Arjun, Dronacharya managed to ensure that Eklavaya would not be the best archer of his time.
If Indian coaches play favourites, why blame them. They are emulating Dronacharya.
Lesson for Software Coaches: Do not play favourites.Nurture talent without any heed to caste, or creed, or region.
12 October 2010
Humility & Courage
Some of those who have worked with me would remember this.
Two absolutely indispensable character traits for software work.
Humility - to say, "I do not know". Never believe anything is a piece-of-cake. There are going to be surprises. Never think your work output is defect-free.
Courage - to move forward knowing that there are unseen pit-falls. It is the courage of a blind person. Do not be afraid of falling. Feel your way. Experiment; take small steps; make mistakes; admit them; and learn from them.
Two absolutely indispensable character traits for software work.
Humility - to say, "I do not know". Never believe anything is a piece-of-cake. There are going to be surprises. Never think your work output is defect-free.
Courage - to move forward knowing that there are unseen pit-falls. It is the courage of a blind person. Do not be afraid of falling. Feel your way. Experiment; take small steps; make mistakes; admit them; and learn from them.
11 October 2010
Custom Processors
Tenselica gives ten reasons to customize a processor.
What about the tool chain? Should be a business opportunity for porting the GNU tool chain.
What about the tool chain? Should be a business opportunity for porting the GNU tool chain.
02 October 2010
Movie about Quality
Early today I watched Executive Suite. It is a movie made in the the 1950s. I strongly recommend getting the bittorrent download, or the DVD (available from Amazon), or watch when Turner Classic Movies schedules it again
The terrific cast include William Holden. Holden was a favourite of mine when I was in school. Some may remember him from Bridge On the River Kwai. The movie very convincingly conveys the message about values on which a company should be run, quality in manufacturing, product that the company's people are proud to stand behind. If American companies had paid heed they would not have lost leadership in automobiles. We need to build companies with the same values.
The terrific cast include William Holden. Holden was a favourite of mine when I was in school. Some may remember him from Bridge On the River Kwai. The movie very convincingly conveys the message about values on which a company should be run, quality in manufacturing, product that the company's people are proud to stand behind. If American companies had paid heed they would not have lost leadership in automobiles. We need to build companies with the same values.
Subscribe to:
Posts (Atom)