Rules for developing software

1. Great software is built by small teams or individuals. If you're building a great BIG software product use lots of small teams or do it yourself to silence critics or find someone to do it for you. The team leaders (if you use a group) should be able to carry on a civilized conversation with others; conversely, they should not be trying to torpedo each others' careers behind their backs.

2. Great software projects always, always have one person who gets the big picture. He/she codes. Repeat: he/she codes. This person is called the architect.

3. Software "architects" that don't code are not software architects. Sorry.

4. If you check in code that breaks the build, shame on you. If you didn't bother to test it before you checked it in, you should be reassigned to writing dot-matrix printer drivers for CP/M for the rest of your natural life.
If on the other hand your checkin broke the build because it conflicted with another checkin, get out of your office and make some new friends among your coworkers. And talk to the architect and get the big picture. If you're really conscientious maybe one day you might be like him/her.

5. In any given source file there should be more comments (as measured by number of ASCII characters, if nothing else) than code. The comments should reflect the fact that the coder knows what he/she is doing and why this code was, in fact, necessary.

Your comments should be comprehensible and grammatically correct. One day you will die, or be transferred to another project, or leave the company, and someone else will take over your code. Think about that.

6. Any coder that puts profanity in his/her code should be forced to write BIOS keyboard interrupt service routines for the rest of his/her natural life, preferably for an eight-bit microprocessor on an S-100 bus.

7. Test/QA is not there to find your bugs. (Read that twice, please.) You are there to find and fix your bugs. (Read that ten times.) Test/QA is responsible for telling manager(s) and customer(s) if your code is any good, and if it's ready to ship.

8. XML does not solve all your problems. Neither does model-driven design, or UML. You still have to write good code. Sorry.

9. Great software architecture requires thought in advance. Sorry.

10. Any coder that doesn't get the importance of user interface design up front should be forced to write IBM System/360 Job Control Language for the rest of his/her natural life.

Any coder working on a client-side app (including web-based apps) that codes without a UI design up front ought to be forced to write programs for OS/2 1.1 for the rest of his/her natural life.

11. Every coder must spend as much time as possible listening to a customer/user complaining bitterly about his/her software and act on the feedback.

12. Julie's Corollary: there is a difference between "programmers" and "engineers." You know who you are.My question-do you?andwhat do you want to become?Are acting to make that happen?

13. Coders with Big Egos usually have Big Problems with their code.

How can you tell a Coder with Big Ego? Easy. They often
a) close their office doors and refuse to talk to anyone who is "unworthy," including marketing, QA, product managers, and their own managers;
b) yell derisively at QA, who have the unmitigated gall to claim their code may have bugs;
c) tell everyone that "no customer would ever do that," when in fact every customer "does that";
d) usually quit either immediately before or immediately after ship, so as not to be accountable.

Pride comes before a fall-the bigger the ego the faster and harder it shatters and hurts you most where you least expect the same.

14. Great coders are not afraid of the words "value proposition." (Converse: good software marketers are not afraid of the words "object model.").A customer/user must actually see value in your work and enable consumers/clients to use the same efficiently.Period.

Become slashdotters (http://slashdot.org) and alterslashers (http://alterslash.org) -and the best coders compete in a no holds barred competition and make do with least-the barest minimum.

15.Learn from failures and improve !

Learning from failure
This is difficult. Writing and publishing encourages me to carefully examine my ideas and helps to clarify them. But looking closely at my own failure hasn't been fun, even if it has been rewarding. Hopefully others can spare themselves the pain by learning from my mistakes.

Back in April, May, and June I had an embarrassingly bad time with the import problem I mentioned. I took three months banging my head against various aspects of the problem. In spite of my post about the importance of knowing when to stop I chased one wrong turn after another for three months. When Rob returned from his vacation he asked Paul to take over who finished it in four days.

Three months vs. four days. That is embarrassing.

It would be easier if I could claim to have solved most of the problem. But Paul's solution little resembled what I had started and addressed aspects of the problem I hadn't even considered. I know Paul is a better programmer. I know he is fast. But I was not prepared for the internal shock and dismay of so glaring a comparison.
With a few months hindsight I can see that I made my most fundamental and most drastic mistake right before I started working on the problem. I assumed it would be easy, but tedious. I underestimated my opponent.
I then failed to notice just how much I was actually struggling. This is especially hard to accept, even in hindsight. How on earth could I go on for weeks, let alone months, without noticing how seriously I had underestimated?
When presented with evidence that conflicts with our beliefs, we dismiss the evidence rather than adjust our beliefs. Getting my butt kicked by an "easy, but tedious" problem is inconsistent with my hot-shot-programmer self-image. I continued to believe the problem was easy and that I was on the verge of the solution, in spite of mounting evidence to the contrary.

The last dimension of failure grew from the same poisoned soil. I couldn't bring myself to ask for help on something "so easy." I didn't want to interrupt Rob and Paul who seemed quite busy on more important matters. I didn't want to admit that this busy-work was kicking my butt. I flailed and struggled and silently suffered along.
As in aikido, getting properly slammed into the mat can really focus your attention. A number of important lessons came hard and fast in July and August.

Sean McGrath's description of the breakthrough syndrome offered some solace, if not a solution:
The syndrome affects all walks of IT professional life but is most acute in software developers. ... The developer "wraps their head" around a problem. ... From that moment of immersion onwards, ideas for solving the problem come thick and fast [and] the developer gets a sense that a triumphant breakthrough is not far away.... That person is likely to feel - really and truthfully - that a breakthrough is just around the corner.It may be, but it probably isn't.

Paul says "there's no busy-work in programming." I haven't heard that anywhere else, and it's still hard to believe. But there's no question that I would have called for help much sooner if I hadn't thought of it as busy-work.
My failure exposed the underlying importance of a collection of extreme programming practices. For starters, my silence violated three of the four XP values, specifically communication, feedback, and courage. Silence is not an effective form of communication. I was cowardly in concealing my failure rather than courageously admitting that Easy and Tedious had beaten me. I broke the feedback loop and we suffered for it.

By contrast, once my failure was out in the open, I was immediately back into the communication and tight feedback loops that are typical for bivio. Rob offered a couple rules of thumb to measure future progress: most tasks should take less than a day and the hard ones should be done in a week. These rules are hidden in continuous integration. In order to integrate continually, you have to break the tasks into day-sized chunks or smaller. Alarms should be going off if you can't integrate your code at the end of the day.

David called for the planning game -- something we hadn't been doing. For this particular problem, the split would have been especially valuable. I had misjudged the problem and taken on a task that was too big for me to properly get my head around. It would have been useful to get help early in slicing the problem into smaller pieces. Also, regularly reporting and adjusting scope and tasks would cause a failure like mine to fail fast. I would only have gone one week before the alarms started going off. If it went as long as two weeks, serious interventions would have been put in place and a months-long failure would have been averted.
I had to get over my hesitation to interrupt. This is about courage and communication. I had two fears holding me back. First, I was afraid of interrupting Rob and Paul. Second I was afraid of looking stupid. Courage is taking action in spite of fear. I need to trust Rob and Paul to manage their own interrupts. The fear of looking stupid is both simple and incredibly difficult. I simply need to get over it. That is substantially harder than it sounds, and also a story for another day.

Update: We only occasionally pair program. Doing that more consistently would obviously prevent a mistake like mine. If we were always pair programming, it would be hard for me to have even developed a fear of interrupting.

Perhaps the most important lesson of this whole experience is about my coworkers at bivio. No one berated me for my failure -- perhaps it was clear that I had that job well in hand. Instead they offered encouragement and stories of their own failures. In some way we bonded through my failure. We looked at the problem as a team and brainstormed various measures to learn from the experience. My mistake became an authentic opportunity to learn and grow, not to judge and condemn. That's not just a slogan on a motivational poster, but what really happened in action

16.Do not give broken links-nothing irritates more if you are not able to substantiate your claims in front of whomever you want to impress!.IBM's latest may make broken links a thing of the past.

(GOAL Create a system that can convert the anarchy of online data„Web pages, e-mail, chat rooms, and more„into a format that can be analyzed to identify commercially valuable information
WHY IT'S A WINNER By leveraging the vast reserves of untapped information online, WebFountain will let companies make smarter business decisions while creating an open platform that will encourage more machine understanding research to leave the laboratory.).