Wednesday, November 15, 2017

What's it like to rewrite a program from scratch?

This is an interesting question because so many programmers are so afraid of this task that they would never even ask it. Is this reluctance agile, or Agile?

But why would you want to do rewrite a program from scratch? The most important reason is to increase maintainability. In the initial writing, the focus is generally on merely getting the job done, without thinking of the program's future. Over their lifetime, many programs cost far more to maintain than to write originally, especially when the original program has become a thing of rags and patches.

A second, and often secondary reason to rewrite a program is efficiency. Newly constructed programs and highly patched old programs sometimes turn out to be slower than desired, but such inefficiency cannot erased by any amount of tweaking. Instead, increased efficiency requires a new approach, an approach that needs to be implemented from scratch.

But isn't rewriting expensive? Not usually. In fact, it’s generally far, far easier to rewrite a program from scratch than to write some brand-new program.

Why would a fresh start-over be cheaper than the original? Because in writing the original program, the original programmers answered so many difficult questions about what was really wanted. Requirements haven't changed, and most of the thought put into testing can be reused.

Those questions—requirements and test—usually make up more than half the total work put into a program. They have already been answered—but only if you resist the temptation to change those answers. If you don’t resist, then rewriting the program can be arbitrarily difficult.

I wish more programmers had to courage to rewrite some clumsy programs from scratch, rather than patch and patch and patch. And I wish their managers would encourage sensible rewriting, rather than force programmers to waste their skills, time, and energy keeping ancient programs on life support.


Tuesday, November 07, 2017

When do I know I'm not a beginning programmer any more?

I was asked, "When do I know I'm not a beginning programmer any more?"

I wouldn’t answer this question, because it’s the wrong question.

You should not ever want to know you’re not a beginner, because a true professional is always a beginner. The world in general, and the world of programming in particular, is so complex, so huge, that one lifetime is not long enough to stop being a beginner.

Your beginner’s mind is one of your most valuable tools. It requires you to look at each situation afresh, and to innovate. (Fundamentally, that's what the Agile movement is all about.) If you know children, watch how they use their beginner’s minds to conquer their world.

I’m very suspicious of people in the programming field who think they are no longer beginners. Myself, I’ve been programming for about 70 years, and I still consider myself a beginner.




Thursday, November 02, 2017

How do I become a programmer who gets stuff done?

The young man wanted to know, "How do I become a programmer who gets stuff done?" He received a number of good answers, like how to organize his work and schedule his working hours. Yet I had a different view of things, so I gave a different sort of answer, as follows.

Some good advice here, yet even if you do all these suggested things, you may be having a different problem. When you speak of getting stuff done, you may be speaking of “finishing” things.

Defining what “done” means has been a classic programmer problem for more than 50 years. Part of the problem is that programmers with different personalities have different ideas about what “done” means. For instance, look at the situation from the point of view of MBTI personality temperaments:

NTs tend to think a project is done when they have a clear description of the problem and a general approach to solving it. Someone else can work out the details.

SJs tend to think a project is done when it’s “code complete”—though research at Microsoft and other places seems to indicate that only about two-thirds of the eventual code has been written by that supposed benchmark. Perhaps this work isn't thought of real programming, but only "clean up."

NFs, such as me, tend to think that a project is done when everyone involved is satisfied that it’s done. Of course, because these "others" are of various personality types, our NF estimate of "done" isn't very reliable.

SPs tend to think a project is done when they are bored with doing it. They share this feeling with lots of other temperaments, too. Programmers in general don't tolerate boredom very well.

Not taking that last step to "clean up" is a curse of our profession, leaving many programs in a less-than wholesome state. Unclean, unfinished programs are the source of many maintenance problems, and of many errors shipped to customers.

Of course, this classification is only a rough model of non-finishers. Many good programmers of all temperaments are excellent finishers, having taught themselves to be aware of their tendencies and counter them with a variety of tactics. Primary among those tactics if the technical review by peers (which is an integral part of the Agile approach but  by no means is not confined to Agile).

So, you offer your “finished” project to your peers for review, and if they agree that it’s finished, you’ve truly gotten something “done.”

If they don’t agree that your work is done, they will give you a list of issues that you need to address before you’re “done.” You then go back to work and address these issues, then resubmit the newest version to another technical review.

Finally, you iterate in this reviewing process until your work passes the review. Then you know you’ve gotten something done.

For more detail on the review process, see, 


Sunday, October 29, 2017

My most challenging experience as a software developer

Here is my detailed answer to the question, "What is the most challenging experience you encountered as a software developer?:

We were developing the tracking system for Project Mercury, to put a person in space and bring them back alive. The “back alive” was the challenging part, but not the only one. Some other challenges were as follows:

- The system was based on a world-wide network of fairly unreliable teletype connections. 

- We had to determine the touchdown in the Pacific to within a small radius, which meant we needed accurate and perfectly synchronized clocks on the computer and space capsule.

- We also needed to knew exactly where our tracking stations were, but it turned out nobody knew where Australia's two stations were with sufficient precision. We had to create an entire sub-project to locate Australia.

- We needed information on the launch rocket, but because it was also a military rocket, that information was classified. We eventually found a way to work around that.

- Our computers were a pair of IBM 7090s, plus a 709 at a critical station in Bermuda. In those days, the computers were not built for on-line real-time work. For instance, there was no standard interrupt clock. We actually built our own for the Bermuda machine.

- Also, there were no disk drives yet, so everything had to be based on a tape drive system, but the tape drives were not sufficiently reliable for our specs. We beat this problem by building software error-correcting codes into the tape drive system.

We worked our way through all these problems and many more smaller ones, but the most challenging problem was the “back alive” requirement. Once we had the hardware and network reliability up to snuff, we still had the problem of software errors. To counter this problem, we created a special test group, something that had never been done before. Then we set a standard that any error detected by the test group and not explicitly corrected would stop any launch.

Our tests revealed that the system could crash for unknown reasons at random times, so it would be unable to bring down the astronaut safely at a known location. When the crash occurred in testing, the two on-line printers simultaneously printed a 120-character of random garbage. The line was identical on the two printers, indicating that this was not some kind of machine error on one of the 7090s. It could have been a hardware design error or a coding error. We had to investigate both possibilities, but the second possibility was far more likely.

We struggled to track down the source of the crash, but after a fruitless month, the project manager wanted to drop it as a “random event.” We all knew it wasn’t random, but he didn’t want to be accused of delaying the first launch.

To us, however, it was endangering the life of the astronaut, so we pleaded for time to continue trying to pinpoint the fault. “We should think more about this,” we said, to which he replied (standing under an IBM THINK sign), “Thinking is a luxury we can no longer afford.”

We believed (and still believe) that thinking is not a luxury for software developers, so we went underground. After much hard work, Marilyn pinpointed the fault and we corrected it just before the first launch. We may have saved an astronaut’s life, but we’ll never get any credit for it.

Moral: We may think that hardware and software errors are challenging, but nothing matches the difficulty of confronting human errors—especially when those humans are managers willing to hide errors in order to make schedules.



Monday, October 23, 2017

Where do old programmers go?

As far as I can tell, I’m the oldest old programmer to answer this question so far. I’m so old that the title “programmer” didn’t even exist when I started.

I celebrate my 84th birthday this week, and as far as I know, most of the programmers who were around under various titles when I started (in 1956, maybe 20 of us in the USA) are now dead. I hope they’ve gone to heaven (the cloud?).

Myself, I gradually ceased writing code for money and transitioned to training younger people to be outstanding professional programmers. I still write lots of code for my own use and amusement and learning, but it’s been at least 40 years since I could tolerate writing code for a boss who didn’t understand what programming was all about.

I’ve earned multiple livings as consultant, teacher, and writer. Always about programming, but more about design rather than coding details as the years went by. If you’re good, you can do any of these things even at advanced age, but you can’t just sit around waiting for someone to find you.

If you’re not good, than either get good (it’s never too late) or retire. We don’t need mediocre programmers, and we never did.


Sunday, October 08, 2017

How Can I Have More Leadership?

I was asked, "How Can I Have More Leadership?"

Many people were interested in my answer, even though I'm not sure whether this question means

How can I have more leadership applied to me?

or 

How can I provide more leadership for others?

In some ways, it's the same question either way. Why? Because if you want more leadership applied to you, the primary way to get it is to provide it yourself.

There are many things you could do to provide more leadership, but I would suggest that before you do any of them, set your mind firmly on this definition of leadership:

“Leadership is the ability to enhance the environment so that everybody is empowered to contribute creatively to the task.”

Don’t forget any of the key words. Check them out when you’re about to do something you think of as “leading.”

  • enhance: you’re making the environment better in some way, and there's lots of way to do that, not one single "leader" way

  • for everybody involved, so make sure what you think is an enhancement is really that for everybody

  • so they’re empowered, which doesn’t mean forced or ordered, especially not by you

  • creatively, not in some stupid or mindless way, and not necessarily in the way you would do it

  • and stay on task, for your job is not to fix everyone else, but to help the job at hand get done

If you keep these things in mind, you won’t always be perfect at leading, but with practice you’ll get better and better, with fewer blunders.




Monday, October 02, 2017

Can they charge me for bugs?

How likely is it that you can create 0 software bugs?

A contract programmer told us, "For years, my client has aimed for 0 bugs on every software release. However we can't control the bugs that closely. Now the client has come out with an idea of charging me a penalty—a cost refund as much as 3% per bugs from what I charge them. What can I do?"

First of all, stop calling them “bugs.”  They are not independently reproducing life forms. They are made by us humans, and there are no perfect humans.

Next, listen to what experienced S/W developers will tell you. Perfect software is a myth, an illusion.

But suppose you did produce a piece of zero-error software. How would you know that’s what you had? I’ve known software that was thought to be error-free for 30+ years, then an error turned up. Are they still going to be charging you penalties thirty years from now?

Quite simply, perfect software violates the Second Law of Thermodynamics. Then, too, software that might be perfect yesterday can become imperfect because of changes in the world today.

But, if they want to charge you for errors detected in software you built, that’s okay. What you need to do is charge them more for the software to begin with, to account for what you will eventually have to pay back. Just set a time limit—maybe a year or so, or until someone else modifies the code. And be sure you have an agreed definition of what constitutes an “error.”

This is not a simple question. I’ve written at least two books on the subject, and ultimately they don't cover every possible variation. But at least give your client a copy of the books so you can begin your negotiation with some intelligent information, not just myths and illusions:





Monday, September 25, 2017

Dealing With Failure as a Developer

He asked, "How do I not feel like a failure when I went to one of the best schools and got one of the top internships, only to be a bad developer in the end?"

And here's what I told him:

First of all, tell yourself how lucky you are that you found out that you don’t happen to be good at development. Lots of people are good at other things, but aren’t good at development, don’t know it, and persist in doing a bad job. You should be extremely happy you’re not one of those clueless people.

Tell yourself that you failed at one thing, so far. Most people in their lives fail at many things. It’s perfectly normal.

The few people who never fail at anything are generally those who never try anything new, or risky. Tell yourself how lucky you are that you’re not one of those jerks.

When we try things, sometimes we succeed, sometimes we fail. But succeed or fail, we always have the possibility to LEARN. Many of the people who do fail at things never take up the possibility to learn, so ask yourself “What did I learn from this failure.” Keep asking like that for each failure, and you will become a very smart person.


It would also be a good idea to learn to use a different way of speaking about yourself. You are not “a failure.” You are a person who failed at something. Once. Therefore, you are a real human being. That’s pretty good, isn’t it?

For some tools to help you work through this feeling of failure, read: More Secrets of Consulting: The Consultant's Tool Kit

Wednesday, September 20, 2017

Which is Better, Writing on Screen or Paper?

I'm frequently asked, "Do writers and programmers feel more creative and expressive with pen and paper, or do thoughts come out as easily as when typing on a keyboard?"



It's a debate that I've listened to for more than half a century. Every tool for writing has some proponents. In other words, there’s no one way that’s better for every writer all the time. That's why the debate will never be settled. Even so, we can learn from it.

Personally, I have published a great variety of work—non-fiction, fiction, poetry, data queries, children’s stories, computer code, advertisements, polemics, applications. I've done so while writing

• by hand with pen or pencil or sharpie or marker pen

• on a manual typewriter or electric typewriter or computer keyboard

• with a stylus on a diver’s slate in a pool or shower

• with my toe in pink Bermuda sand

• with my voice into a recorder or computer voice-to-digital app

• with my bare finger on a touch screen

• with an electric router on a wooden beam

I may have used other approaches, but I can’t remember what else. I'm pretty sure, though, contrary to rumor, that I have not yet written with a hammer and chisel on a stone tablet. Something to look forward to.

Moral #1: if you’re a real programmer or writer of any kind, you would never let the lack of your favorite medium stand in the way of your writing.

Moral #2: If you want to be a real programmer or writer, for heaven’s sake, experiment with any medium you can imagine. You’ll find, as I did, that certain media are better for capturing your voice for each different coding problem, each different story, and each different type of writing.

So if your favorite tool isn't available, don't whine and don't shut down. Experiment instead!

Even if your favorite tool is available, experiment!

Besides, your primary tool is you, not the pen or keyboard or chisel, so keep experimenting with all those secondary tools that help you discover yourself.


And read Weinberg on Writing: the Fieldstone Method, which has taught thousands of writers how to experiment with their writing under every imaginable circumstance.

Thursday, September 14, 2017

What should be my next step to becoming a better programmer?

What's your next step?

I'm guessing, but if you’re like most programmers, you’re already too involved in technical details, You may have mastered Python, Java, Ruby, C++, or a dozen other languages and platforms, but your ability to deal with other people is less than adequate.

Studies of programmers at work show that typical programmers spend 70% of the time dealing with other people. (Agile programmers may spend even more time). [See, The Psychology of Computer Programming]

- Do you ever misunderstand what you've been asked to do?

- Are you ever misunderstood when explaining what you're trying to do?

- Do you ever have fruitless arguments with your boss? With your coworkers?

- Do you ever have trouble dealing with people who are not as smart as you?

- Do you sometimes have trouble dealing with feedback about your performance?

If so, and you want to improve, perhaps you should devote some time to developing your People Skills.

At the very least, you'll learn how to solve "people problems" more efficiently, thus leaving you more time, in a better mood, to do the technical work of programming.


Next step? Take a look at this bargain bundle:



Sunday, September 10, 2017

False Urgency


What should I do with a client or boss who insists that a certain task is urgent, but it turns out to be likely a false alarm?

In your mind, subtract 10% from this persons trust account, then watch for the second occurrence. It might be a one-time mistake or it might be a person who thinks every little thing is "urgent."

If it happens again, tell him or her that you charge double (or triple) for urgent tasks. If he or she isn’t willing to pay, then find another client.

If you're an employee and this is your boss, you obviously can't charge them with money, so you have to find another way to make them pay. My favorite way was simply to ignore them and proceed at my normal pace, in priority order. I never got fired for doing that, particularly when it became evident to everyone that the urgency was false.


This is just one of the ways you have to train your clients and your managers if you want to be a successful employee, contractor, or consultant.

Thursday, September 07, 2017

Must There Always Be Inferior Code?

Some people claim that when you learn high software standards you will never again develop in inferior ways. Is this true?

I think you can arrive at a meaningful answer by using an analogy:

Some people claim that when you learn high medical standards, a doctor or nurse will never again treat a patient in inferior ways. Is that true?

Seen in this light, the answer is obvious. Most doctors and nurses will not treat patients in inferior ways—unless it's an emergency, like an explosion or a fire in which many people need saving in a hurry. If that happens, the doctor or nurse will return to those patients when the emergency has calmed down. Same in software.

But there do exist a few medical professionals who don’t live up to such high standards. They are, after all, human beings. Yet in spite of their inferior practices, some of their patients do get better. Why? Because humans have built-in healing mechanisms—but software does not.

Software with sick code doesn’t heal itself. Those programmers who develop in inferior ways will eventually produce troublesome code. But the key word is "eventually."

The inferior programmer may not be around any longer when the code's trouble makes itself known, so some inferior programmers can get away with hacky ways for an entire career.

It’s a good manager's job to recognize these inferior programmers and replace them and their code before the true costs of their inferior work become evident.

Some managers overuse the tactic of forcing programmers to code in a hurry, as if there's always an emergency. Just as in medicine, emergency treatment of code tends to produce inferior results. Managers who care only about the short-term will not do anything about their inferior programmers, but they, too, may move out before the consequences of their inferior management become apparent.


That’s why inferior programming practices persist. And, as long as programmers and managers are human, inferior practices will always persist. But they don't have to persist in your world. It's up to you. \

Code in haste, debug forever.

Sunday, September 03, 2017

Why is reading or writing something different from doing something?

First consider reading. Reading is (usually) a solitary activity, with no feedback. Without feedback, there's no check on what you believe you're learning.

Now, writing. Unless you put your writing in the hands of someone (or perhaps some computer analysis app), there's also no feedback, so there's no check on whether you wrote sense or nonsense.

When you do something, you interact with the real world, and the world responds in some way. With the world's feedback, you have the possibility of learning, confirming, or disconfirming something. That's why we strongly favor experiential learning over, say, lecturing or passive reading or writing.

If you want to teach somebody something, don't just send them to a book, or, even worse, tell them what you want them to know. Instead, figure out a way to have them experience the situation in which the learning applies.

After they've had the experience, you then might want to send them to a book where they can read about what they experienced.  Alternatively, you might ask them to write about their learning and have you read what they wrote.

You can try this out:

Step 1. Write a sentence or two about what would happen if you tried to move your desk six inches (15 cm) to the left or right.

Step 2. When you finish writing, get up and move your desk six inches (15 cm) to the left or right.

Step 3. What did you learn in steps one and two?



For a far more thorough answer to this question, see my four-volume series on Experiential Learning 



Then do some of the experiential exercises you find there.