skip to main | skip to sidebar
Showing posts with label development. Show all posts
Showing posts with label development. Show all posts

Monday, April 09, 2018

How can I become a software developer who only designs?

A young programmer asked me, "How can I become a software developer who only designs the whole software architecture and gives instructions to other developers rather than actually coding by myself?"

I told him he could do that right away, as long as he didn’t care if the other developers listened to his instructions and followed them. And if he didn't care of he was paid.

In general, software developers will not follow the lead of someone for whose designs they have no respect. And why would they respect your designs unless you had previously proved yourself by what you’ve built?

So, build things, and build more things, until you demonstrate that others have some reason to follow your lead.


And, at the same time, work on your people skills, because even if you’re the greatest designer in the world, if you’re a self-centered jerk, nobody will follow you or your designs.

For more on designing, see

Wednesday, December 06, 2017

What is the simplest, most amazing code you have ever written or witnessed?

We were asked to describe the simplest, most amazing code we had ever written or witnessed.

My answer should probably be some esoteric APL code that I personally wrote, like inverting a matrix with a single character program, but many of my readers wouldn’t understand it. In any case, modesty prevents me from choosing my own code.

So, instead, let me tell the story that took place long ago when we were installing an IBM 709 in Bermuda, as part of the NASA space-tracking network. The 709 was a “naked” installation, with little surrounding peripheral equipment, and nothing like it in Bermuda to help us.

In particular, we didn’t have an off-line printer or a punch-card duplicator, so we needed to use the 709 itself to do these jobs—but we had no utilities because we were probably the only naked 709 in the world.

My colleague, Marilyn, who was by far the best programmer I ever knew, went to our keypunch (the only unattached peripheral we had), inserted a blank card, and proceeded to punch (in row binary) a card-to-card duplicator program for the 709. She did it as I watched, in a single pass through the keypunch.

You’d have to understand row-binary format to appreciate what a feat this was—multiple punched columns of alternate instructions in binary. To top it off, she actually punched in (in the same pass) the self-loading program AND the parity check row for her entire card.

She then loaded this card into the 709’s card reader, picked it up and reentered it as input to itself, and so punched a duplicate. She took the duplicate to the keypunch and added one punch to one of the rows. She now had a 709-to-printer program—two incredible error-free programs for the price of one.

I’ve never seen anything like it before or since. Until that time, I thought I was a pretty good programmer. After Marilyn’s feat, I realized that the best I could ever hope to be was Number Two.

How about you? Any amazing code stories to share?



Posted by Gerald M. Weinberg at 4:14 PM 8 comments

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,


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.


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, August 23, 2017

Basic skills of a good programmer?

Many outstanding programmers were asked, "What are the basic skills required to be a good programmer?" Lots of good and useful answers were given to this question, such as, test before coding, use a particular tool, or use Agile methods.



For me, though, with more than 60 years of programming experience, the one thing that made me a better programmer was my ability and willingness to examine myself critically and do something about my shortcomings. And, after 60 years, I'm still doing that. You could say it's incremental development applied to myself.

I also examine my strengths (long-comings?) because I know that my greatest strengths can quickly become my greatest weaknesses.

For instance, one of my great strengths as a programmer was speed. If something had to be done quickly, I was the guy to do it. But the weakness in my speed was my tendency to omit the last few hours of testing that would make the project rock solid. I had to learn the importance of taking the time to do a precision job.

Many programmers do examine themselves critically, but then they work to improve their greatest strengths, to the exclusion of their weaknesses. That practice takes them a certain distance, but the nature of computers is to limit your ability, by highlighting your greatest weaknesses.

A computer is like a mirror of your mind that brightly reflects all your poorest thinking. To become a better programmer, you have to look in that mirror with clear eyes and see what it's telling you about yourself.

Armed with that information about yourself, you can then select the most useful external things to work on. Those things will be different for you than for anyone else, because your shortcomings and strengths will be unique to you, so advice from others will often miss the mark.

Good programmers make good use of their best tools, and you are your best tool, so sharpen yourself.


See, for example,





Thursday, June 29, 2017

Improving as an Agile Developer

The question was posed: "I'm on an Agile team, and I'm undoubtedly the least experienced member. What could I do to improve my software development skills?" Here's what I answered:

There are many things you can do to improve, and I’m sure you’ll get some good answers. If your Agile team is worthy of its name, you will certainly improve by working with them, reviewing their code, and having them review yours.

From my point of view, however, there is one thing to do that underlies all the other suggestions, and especially learning from your teammates:

Never pretend you know what you don’t know.

Always be ready to ask for help in learning new things.

You may think you have to look extra smart and experienced to impress your teammates, but it’s quite the opposite. Just show your willingness and eagerness to learn. Besides, your Agile teammates will always figure out if you're faking.


Some people might not value this approach, but they’re not people you want to associate with. They’re probably pretenders themselves. They're certainly not good Agilists.

Sunday, June 25, 2017

How do I get better at writing code?

Nobody writes perfect code. Anyone, no matter how experienced, can improve. So, you ask, how do I get better at writing code?

Of course, to get better at writing code, you must practice writing code. That much is obvious. Still, just writing the same poor code over and over, you're not likely to improve by much.

Writing is a different skill from reading, but reading code is necessary if you want to improve your writing. As with writing natural language, you build up your skill and confidence by reading—and not just reading your own output. So, find yourself some examples of good, clear code and read, read, read until you understand each piece.

Be careful, though. There’s lots of terrible code around. You can read terrible code, of course, and learn to analyze why it’s terrible, but your first attention should be on good code. Excellent code, if possible.

Where can you find good code? Textbooks are an easy choice, but be wary of textbooks. Kernihan and Plauger, in their book, The Elements of Programming Style, showed us how awful textbook code can be. Their little book can teach you a lot about recognizing bad code.

But bad code isn't enough. Knowing what's bad doesn't necessarily teach you what's good. Some open source code is rather good, and it’s easy to obtain, though it may be too complex for a beginning. Complex code can easily be bad code.

Hopefully, you will participate in code reviews, where you can see lots of code and hear various opinions on what’s good and what’s less than good.

Definitely ask you fellow programmers to share code with you, though beware: not all of it will be good examples. Be sure the partners you choose are able to listen objectively to feedback about any smelly code they show you.

If you work alone, use the internet to find some programming pen pals.

As you learn to discern the difference between good and poor code, you can use this discernment in your reading. After a while, you’ll be ready to start writing simple code, then work your way up to more complex tasks—all good.

And date and save all your code-writing examples, so you can review your progress from time to time.


Good luck, and happy learning!

Monday, June 05, 2017

Is Waterfall the Opposite of Agile?


Agilists sometimes behave unreasonably by pummeling the Waterfall approach. Personally, I think such evangelists could better spend their effort producing solid, relevant code, but evidently they are on a crusade and need an enemy. If they need an enemy of Agile, however, they could have made a better choice.

There's nothing wrong with the Waterfall approach—if applied appropriately. For Waterfall to work well, you need to solve a problem that's not destined to change much, or, ideally, to change not at all. Some Agilists claim there is no such unchanging problem, but they're merely showing their lack of experience. I've seen a number of such invariant problems, and they yield very readily to a properly applied Waterfall development.

For example, Erik, a former student of mine, made a lucrative business of converting COBOL programs to new COBOL programs adapted to new versions of the COBOL compiler. Erik's customers wanted assurance that nothing would be changed in the conversion. This was a perfect situation for a simple Waterfall approach, one that Erik could perform profitably at a fixed price and schedule.

That said, the number of such invariant problems is not large, and it's usually difficult to know at the beginning if a problem will turn out to be so stable. In Erik's case, some of his customers would decide midway that they wanted a few "tiny" improvements in the converted application. Erik controlled that situation by charging outrageous fees for even the simplest modification. Most of us, however, try to control this situation by employing some Agile approach.

Let's be honest with ourselves: one consequence of an Agile approach is the loss of our ability to work to a fixed cost on a fixed schedule. Erik could do that, but only in a few carefully controlled situations. Many managers frustrate themselves over this lack of control and blame it on Agile. What's really to blame, however, is their inability to control the world in which they live. Things do change, and much of the time it's these very managers who instigate the change.

What do frustrated managers do? Quite often, they elevate their attempts to control the change by making rules. They may start using a pure Waterfall approach, but as their frustration with changes grows, they may add a Change Control Board, or change reviews, or a Change Tsar, or any of a number of other tactics. And, when those tactics fail to produce absolute predictability, they add more of the same kinds of rules and their supporting tactics.

After a while, these rules upon rules produce an approach that, though called "Waterfall," is actually something quite different—something for which we so far have no accurate name. This "something" is what Agile is responding to, so I suggest we name it.

What are these cobbled-together approaches like? First of all, they create a sad and dismal mood among those poor developers condemned to use them. When I visit a new client, I can generally detect the use of such an approach while I take a stroll through of the premises. I can even detect such approaches over the phone. How? Simple: the mood of my clients is mournful, gloomy, sad, unhappy, doleful, glum, melancholy, woeful, miserable, woebegone, forlorn, somber, solemn, serious, sorrowful, morose, dour, cheerless, joyless, and dismal.
That's quite a sobering list of adjectives, but that's what I can sense in many so-called "Waterfall" environments. Perhaps you recognize the list, but in any case, you can find that list in your dictionary as synonyms for the rare word, "lugubrious."

Perhaps the word "lugubrious" is unfamiliar, but that's good, because we won't often find it used in other contexts. Besides, it's a rather onomatopoetic word—a word that phonetically imitates, resembles or suggests the source of the sound or situation it describes. That's why Agile was invented—to replace those mournful, gloomy, rule-dominated approaches with brain-driven judgments of the actual builders.

So let's be truly Agile and stop bashing the true Waterfall approach. Instead, let's turn our contempt on every Lugubrious approach—or, to make a noun from the adjective, Lugubriousity. Maybe this more accurate name will help us defend our Agile projects from frustrated managers' attempts to smother us with yet more rules.

Or, to paraphrase DeMorgan, who in turn paraphrased Swift:

Great rules have little rules upon their backs to spite 'em,
And little rules have lesser rules, and so ad infinitum.


Never forget that's why we do Agile, not to dry out Waterfalls but to defeat Lugubriosity.

For more thoughs on the Agile approach, see

Sunday, March 12, 2017

Classifying Errors

I received an email the other day from Giorgio Valoti in Italy, but when I wrote a response, it bounced back with "recipient unknown." It may have been a transient error, but it made me think that others besides Giorgio might be interested in discussing the issue of classifying errors, so I'll put my answer here and hope Giorgio will see it.

Here's the letter:

Dear Mr. Weinberg,
My problem is that I’m looking for good way — maybe a standard, more likely a set of guidelines — to classify and put a some kind of label on software defects.

Is there such a thing? Does it even make sense trying to classify software defects?
And here's my reply:

Hello, Giorgio

It can certainly make sense to classify errors/defects, but there are many ways to classify, depending on what you're trying to accomplish. So, that's where you start, by answering "What's my purpose in classifying?"

For instance, here are a few ways my clients have classified errors, and for what purposes:


- cost to fix: to estimate future costs

- costs to customers: to estimate impact on product sales, or product market penetration

- place of origin in the development cycle: to decide where to concentrate quality efforts

- type of activity that led to the error: to improve the training of developers

- type of activity that led to detecting the error: to improve the training of testers

- number of places that had to be fixed to correct the error: to estimate the quality of the design

- and so on and on

I hope this helps ... and thanks for asking.

--------------end of letter-----------

As the letter says, there are numerous ways to classify errors, so I think my readers would love to read about some other ways from other readers. Care to comment?

Monday, November 28, 2016

How do I find cheap freelance hardware and software developers?

The question was, "How do I find cheap freelance hardware and software developers?"

I warned the questioner to be very careful about what he was asking for:

First of all, you don’t want “cheap” developers; you want inexpensive developers.

Second, the expense of developers is not their hourly or daily rate. It’s the total cost of building and delivering the software and hardware you want.

In my experience, the least expensive developers have much higher rates than the more costly ones. The deliver what you want, the first time, in less time, with less trouble.


However, a high hourly rate doesn’t guarantee an inexpensive product. Freelance developers can charge anything they want, so price doesn’t necessarily indicate value.

Instead, speak to references about any developer you’re considering. Find out first hand what you’re going to get for what you’re paying.

And, by the way, don't think you'll save money by hiring individual developers. Your best bet will generally be to choose a team, perhaps an Agile team, but in any case, a team that has a history of working well together.

Monday, October 31, 2016

What's the most complex thing about software development?

What's the most complex thing about software development?

Interesting question.

So far, on Quora.com, there have been four excellent answers to this question: discussing
- the confusing role of people,
-the requirements problems,
-the interactions with the physical world.

Each of these factors certainly makes software development more complex, and processes such as Agile are designed to cope with this complexity. But, the ultimate complexity factor is software testing.

Why testing? In the software development literature, testing is not usually treated as a glamorous part of development, but when we're testing, we're up against the Second Law of Thermodynamics, which warns us that perfection is ultimately unobtainable.

So, even if we absolutely knew all the requirements (which we can't, of course), kept all the human factors under control (also impossible), and knew exactly all the physical properties of the real world (once more, impossible), we would still never be able to perform the infinite number of tests to cover all possible situations.

In other words, the software could still surprise us at any time. That's what I call complexity.

Of course, we can still work hard to solve these other problems. On requirements, for instance, see our Exploring Requirements books.





But no matter how hard you try, you'll still be faced with the testing problem. To understand this problem and what you can do to reduce (but not eliminate) it, take a look at Perfect Software and Other Illusions about Testing.

Sunday, October 09, 2016

improve my coding skills?

The questioner wrote, "Besides practicing, what else can I do to improve my coding skills?"

I took up the challenge with a warning:

Be careful of practice, because if that’s all you do, you’ll just be reinforcing your bad habits.

Instead, read and understand the coding of others. Reviewing code is the fastest way to improve your own code. If the reviewed code is well done, you learn good techniques. If it’s badly done, you learn what things to avoid.

If you’re on an Agile team, reviewing the code of others will be a natural part of your work, and you’ll also learn from others’ reviews of your work.

In any case, one of the very best ways to read and understand the code of others is by participating in software testing. By testing, you learn what really works and what really causes trouble.

And, of course, you should always take the opportunity not just to study code, but to watch others actually producing that code. What tools do they use? How do they use them? What’s their thinking process? What do they read to learn?


Finally, read some good books about thinking, reviewing, and learning. I’ve written some, and my own books refer to others. (http://www.geraldmweinberg.com)

Wednesday, August 17, 2016

How does a tester help with requirement gathering?



The question was posed: "How does a tester help with requirement gathering?" A number of good, but conventional, answers were given, so I decided to take my answer to a meta-level, like "what is the tester's job, generally, and how does that relate to this question?"
The tester’s job is to test, that is, to provide information about the state of a system being built or repaired. Therefore, the tester should help with requirement gathering or any other phase of development where the job of testing might be affected.
A professional tester will involve her/himself in all phases, not such much to “help” others do their job, but to assure that s/he will be able to do a professional job of testing. So, for example, in the requirements work, the tester should obviously monitor any requirements to ensure that s/he can test to see if they’re fulfilled. The tester should block any vague statements such as “user-friendly” or “efficient” or “fast”—to take just one example.
Moreover, requirements are “gathered” in many ways besides an official requirements gathering phase, so the tester must always be on the alert for any way requirments can creep into the project. For instance, developers frequently make assumptions based on their own convenience or preferences, and such assumptions are not usually documented. Or, salespeople make promises to important customers, or put promises in advertisements, so a tester must spend some time speaking (at least informally) to customers—and also reading ads.
In short, a tester must be involved right from the very first moment a project is imagined, with eyes, ears, and, yes, nose always on the alert for what must be tested, how it must be tested, and whether or not in can actualliy be tested. That's the way a tester "helps" the requirements gathering and all other phases of a project's life, on alert for anything that could affect accurately documenting the state of the system.

As a consequence of this broad view of the tester's job, a tester has to resist any assertion that "you don't have to be involved in this phase," regardless of what phase it is. Obstacles to testing can arise anywhere.


Subscribe to: Posts (Atom)
 

AltStyle によって変換されたページ (->オリジナル) /