7.18.2003
There is a tension between a programmers pride in work, and egoless programming. How can we say that a programmer should care about the quality of code that they produce, while at the same time asking them to be not too bound to there code?
With egoless programming we say "You are not your code. Remember, the entire point of a review is to find problems and problems will be found. Don't take it personally when a problem is uncovered. ". We ask that programers be accepting of reviews as it is not a reflection of them that is being reviewed but rather their code. On the other hand we say that they should take pride in their work as it IS a reflection of them.
(0) comments
With egoless programming we say "You are not your code. Remember, the entire point of a review is to find problems and problems will be found. Don't take it personally when a problem is uncovered. ". We ask that programers be accepting of reviews as it is not a reflection of them that is being reviewed but rather their code. On the other hand we say that they should take pride in their work as it IS a reflection of them.
7.16.2003
From the book "MY 500 DAYS AT APPLE" by Gil Amelio page 130
Chapter 9: Nerd’s Labors Lost and Found - SOLID GUIDELINES FOR NEW PRODUCTS
Why were we doing such a rotten job in product quality? I may not have followed up on how flowers were brought into my office, but I sure wanted to know what had caused the sorry state in the quality level of apple products. We had approximately 650 people throughout the company working on quality leader, and it felt like we couldn’t ship a single product that wasn’t plagued by either design or quality difficulties.
Companies normally expect to spend about 1 or 2 percent on quality. Not even counting warranty costs, we were spending on aver-age 5 or 6 percent.
The reason, I eventually discovered, was another long-time flaw in company behavior. Some Apple engineers, instead of finishing a product and turning it over to the quality people to get their blessings on it, were operating with the attitude, “why put in all that effort? We’ll just get it pretty far along, and then let the Quality guys find the problems. “So they were in the habit of turning their projects over to Quality prematurely. Quality would find flaws and send the product back. The engineers would do some more work, and send it over to Quality again. And it would continue bouncing back and forth until it appeared to be ready. Meanwhile the product launch date had probably been missed, and the release version likely had some lingering problems that slipped by undetected in the under-the-gun pressure to get the product to market.
Quality is supposed to be designed in by the engineers to begin with, not painfully arrived by the expedient of fixing whatever problems you manage to discover. And the proper task of the quality organization is to confirm the fact that the engineers have successfully created a trouble-free product. The Quality troops had become a kind of secondary engineering organization, and had bloomed in size because of it. At budget time, everyone would complain that the quality organization was getting to much money. As bizarre as this sounds, the biggest complainers would be the engineering people, sounding off that there were to many folks assigned to quality.
I would soon lean on the engineers, trying to implant anew perspective on all quality issues. “you should be embarrassed when the quality organization rejects a product you’ve submitted. Tour goal should be use them so that they help you build a bullet-proof product. When it’s completed, all they should need to do is put their stamp of approval on it. “Eventually there would be signs of headway, but this better system took hold only very gradually.
(0) comments
Chapter 9: Nerd’s Labors Lost and Found - SOLID GUIDELINES FOR NEW PRODUCTS
Why were we doing such a rotten job in product quality? I may not have followed up on how flowers were brought into my office, but I sure wanted to know what had caused the sorry state in the quality level of apple products. We had approximately 650 people throughout the company working on quality leader, and it felt like we couldn’t ship a single product that wasn’t plagued by either design or quality difficulties.
Companies normally expect to spend about 1 or 2 percent on quality. Not even counting warranty costs, we were spending on aver-age 5 or 6 percent.
The reason, I eventually discovered, was another long-time flaw in company behavior. Some Apple engineers, instead of finishing a product and turning it over to the quality people to get their blessings on it, were operating with the attitude, “why put in all that effort? We’ll just get it pretty far along, and then let the Quality guys find the problems. “So they were in the habit of turning their projects over to Quality prematurely. Quality would find flaws and send the product back. The engineers would do some more work, and send it over to Quality again. And it would continue bouncing back and forth until it appeared to be ready. Meanwhile the product launch date had probably been missed, and the release version likely had some lingering problems that slipped by undetected in the under-the-gun pressure to get the product to market.
Quality is supposed to be designed in by the engineers to begin with, not painfully arrived by the expedient of fixing whatever problems you manage to discover. And the proper task of the quality organization is to confirm the fact that the engineers have successfully created a trouble-free product. The Quality troops had become a kind of secondary engineering organization, and had bloomed in size because of it. At budget time, everyone would complain that the quality organization was getting to much money. As bizarre as this sounds, the biggest complainers would be the engineering people, sounding off that there were to many folks assigned to quality.
I would soon lean on the engineers, trying to implant anew perspective on all quality issues. “you should be embarrassed when the quality organization rejects a product you’ve submitted. Tour goal should be use them so that they help you build a bullet-proof product. When it’s completed, all they should need to do is put their stamp of approval on it. “Eventually there would be signs of headway, but this better system took hold only very gradually.
Specifications should be detailed
Specifications should be written in a detailed form so that there is no doubt over what needs to be done. All details (the complete spec) needs to be written done. If the spec is not written in enought detail how would it be possible for the programmers to implement it?
I have been playing with the idea of keeping the detailed spec in a bug control system as a list of tasks.
(0) comments
I have been playing with the idea of keeping the detailed spec in a bug control system as a list of tasks.
7.09.2003
Politics is the use of speech to get others to do your bidding.
Management is convincing others to do as required.
Management is politics. Don't be upset that management plays politics, thats their job. The only issue is keeping it for the benefit of the company.
(0) comments
Management is convincing others to do as required.
Management is politics. Don't be upset that management plays politics, thats their job. The only issue is keeping it for the benefit of the company.
7.07.2003
I picked up a hitch-hiker on my drive today. He studied some talmud while I drove. As I drove I realised that there is a similarity between reading Gemera and debugging. In each case you read the text with a few hypothesis in mind until eventually you come across a piece of evidence that eliminates one hypothese after another until only one is left. You then take your remaining hypothese as truth.
(0) comments
7.03.2003
Business Oportunity
What makes the internet so much cheaper than the telephone system is that it is packet based, also that fact that it uses routeable packets provides reliability at a cheap price. FedEx revolutionised the package delivery industry by shifting to a hub based system of package delivery. Packages go from a source to a hub (posiibly to more hubs) and then to the end-user.
WebVan tried to have packages sent point-to-point precisely the problem that FedEx replaced. Instead why not have it work as a hub system where once a day it delivers all your packages to you. This would avoid the problem where people aren't home to recieve packages, as the new system would always be home.
It could be priced as a monthly fee regardless of actually usage. This would provide an incentive to use the system as it would not cost extra for each not item added. Consumers seem to like have a predictable cost over micropayments. There seems to be no reason why it should cost more than delivery of a pizza would cost. It might even be possible to the deliveries to happen at "strange" hours based around when a phone call would be recieved to deliver now.
This system would make it more practical for web-based grocery shopping to work. Anyone who has tried to go shopping with children knows that it takes a lot of extra effort than going on ones own.
7.02.2003
Reverse logic
When you don't know what you are doing, don't make a schedule. Then you can't be late in delivery. True, you can't get it done early either, but then remember the goal is to avoid complaints, not to do the best job. Further there can't be complaints that you left out features, as they were never in the schedule to be done.
