ed weissman

Great question. Ask it to n programmers and get n^2 responses. This could easily be the subject for another post or even a book. Just off the top of my head in no particular order:

- understands the problem at hand before writing any code 

- uses the right tool for the right job 

- follows accepted standards and protocols without sacrificing creativity 

- names variables & functions what they actually are for the next programmer 

- anticipates what could go wrong before relying on a debugger or testing 

- understands the underlying architecture and how to best utilitze it 

- never writes the same code twice 

- never writes in 150 lines that which could be written in 100 lines 

- Poor code: uncommented. Mediocre: commented. Good: doesn't need comments. 

- understands the entire code life cycle & writes it to last 

- has pity on the poor soul who has to maintain it & leaves a clue or 2 

- writes flexibly enough to be easily changed before the project is done 

I could go on and on, but you get the idea. In general… 

A good programmer writes it right, once, in a week. 

A mediocre programmer writes it OK, in 2 months, and then futzes with it forever. 

A bad programmer never gets it done.

If you come to the realization that work in itself isn’t evil, you can stop living your life as a waterfall-planned software project too. 

Nothing wrong with waterfall-planning if it’s done properly. Problem is, it usually isn’t. 

I understand that sometimes you need to release early and often. This is when you can’t conduct proper anaysis. Why not? Because you’re trying for a home run building something big and you don’t know where your project will take you or who will eventually use it. Like a Web 2.0 or social site. 

But for the rest of us, waterfall-planning is just another name for the Systems Development Life Cycle (SDLC), which is an excellent way to develop systems. But you must conduct analysis first. You must answer the question what before you examine the question how. 

Most developers do not know how to do this. How can you tell? When their waterfall phases take too long (more than a month for analysis for most projects). When they say things like, The user doesn’t know what he needs. Yes he does. You just have to keep digging until you know. 

Once a good programmer learns how to conduct analysis he becomes a good developer. Then projects become like shooting fish in a barrel. You biggest problem will be convincing your customers that you can do what they think can’t be done. 

If you’re going to “diagnose the state of your data”, why not clean it up. There’s so much that you can do at entry time, at retrieval time, and at any time between:

- wash non-printable characters 

- wash illogical (depending upon context) characters 

- trim leading and trailing spaces 

- verify check digits 

- verify lookups 

- verify against standards (USPS, etc.) 

- add Soundex, Metaphone, levenshtein, etc. 

- build a context suitable hash 

- add Soundex, Metaphone, levenshtein, etc. to the hash 

- wash standard keywords 

I have had people come to me with seemingly complex problems requiring what they thought would be complex solutions. Oddly, the elegant solution was often a gross simplification of the complex problem. Often because I just didn’t understand the complexity. 

Example 1. A shipper can only fit 1200 boxes in a 40 foot trailer. The material is so light, they can never make weight. The boxes must be delivered to depots throughout the United States with no more than a 3 day window either way. What box should go on which truck? The customer thought they needed sophisticated algorithms to provide an optimal solution. The simple solution: a screen where an educated user can drag boxes (or groups of boxes) to trailers and can drag trailers to destinations. The computer did very little, but the difficult business problem turned into a “game” that employees fought each other to “play”. 

Example 2: A cloth manufacturer wanted a linear algebra solution to determine what products to mount on their mills and where to set the knives. The simple solution: A screen with all customer orders and key data about each order (size, weight, width). Everything on the screen was sortable and switchable. Again, an intelligent user could “play a game” to schedule the mills almost as well as any automated algorithm. 

Example 3: A distributor wanted to know what to buy, when to buy it, and what to put on sale to move slow inventory. He wanted an expensive ERP program. The simple solution: A screen with all supplies and demands that can be mixed, matched, sorted, and selected in many different ways. Again, an intelligent user can “play” with his data and then confidently make decisions. 

The “real” bonus of all these “simple” solutions? The person drove the decision and felt in control of the situation. No more blaming the computer for the results. 

My suggestion: Slow down. Even stop. Ask, “How are we making this too complicated? What simple little thing could I do to get just part of the way there?” You may surprise yourself and find that the simple little idea IS the solution. 

Long gone are the days when the “system analyst” met with the users, wrote tight functional specifications and handed them to the “business programmer”. In any organization that actually gets anything done, the two are now one position, the “programmer analyst”, and it’s been that way for 20 years now. 

And what does a programmer analyst have to do? 

- examine and understand almost any business situation 

- solve technical and logistical problems 

- present ideas clearly and cleanly 

- organize and manage time and tasks 

- play nicely with others 

- and, oh yea, code 

And where do you find people who can do these things? Lots of places, but the 2 that come to mind first are from work experience or college experience. Nobody actually believes anymore that you’ll use anything from class in your work. But it can be a very good place to develop the life skills needed to be a programmer analyst. 

Nobody’s going to ask you to write a linear programming model using the simplex method to determine how to allocate continuous inventory to customer orders. (OK, maybe they will.) But they will wonder why Mary and Joe can’t seem to figure out how to use Program ORP560 to generate this month’s performance metrics.

Is the problem with them or the program? They’ll tell you to figure it out and fix it. Count on it. And count on college to help you become the kind of person who can do that. 

Better to ask first. 

Problem is that systems analysis is a lost art. People don’t know HOW to ask. 

People know what they want. They just don’t know that they know. 

Here are just a few to the things you have to do (that almost no one does anymore) in order to elicit requirements: 

- Spend time with users doing what they do, asking questions until you understand how things work. If this means sitting at their desk, following them around their office/factory/route, or wading hip deep in , then DO IT. 

- Ask questions to groups of people at the same time, so they can argue with each other and learn together what’s really needed. 

- Ask lots of “Yes/No” questions. 

- Ask lots of “On a scale of 1 to 10…” questions. 

- Ask lots of “What is the probability that …” questions. 

- Cover the wall with paper and draw pictures of EVERYTHING. Leave the paper there for all to see for weeks. Let them understand and learn together. 

- Put every piece of paper they use in their jobs (or personal life) on the wall, so they (and others) can really see what they have to deal with on a daily basis. Not blank sheets, but paper with real data on it. 

- Identify every data element. How do you know when you’re done? Keep asking until there are no more answers. 

- Feed people while you ask them. (Amazing how smart people get while eating pizza.) 

- Then (and only then) give them a prototype to play with. (I suppose here is where your “measure” comes in to play.) 

- Exactly right? No? Keep going until it is. 

Aside from the prototype, we haven’t written a single line of code. Is this hard? Absolutely. Maybe that’s why most of us don’t do it anymore. Does it work? It you know what you’re doing: every time. 

(Aside: Notice I never mentioned using crap like Rational Rose or UML. That stuff was never meant to help this process. It was meant to make people who don’t know what they’re doing appear as if they did. Built an industry by paying junior people $50k and billing them out at $250/hour.) 

Single entry/single exit refers to ANY process, not just functions. Don’t underestimate the hell who can go through with poor variable naming. Case in point: 

2 months ago, a client needed significant changes to a major process in their app. (I had 2 weeks.) This process was a BASIC subroutine called by 16 other processes. Now get this: It was 2800 lines of code with one entry and 16 different exits. It was written in 1991 and had been modified 68 times before I came along. 

Here are a few of the variables: A, AA, AAA, AAAA, B, BB, BBB, BBBB, C, CC, CCC, CCCC, INFO, FORM1, FORM2, FORM3, HOLD.FORM2, OLD.FORM2, ORIG.FORM2, STUFF, DUMMY1, DUMMY2, 

DUMMY3… You get the idea. I spent 4 days renaming variables before I could start refactoring. There were some variables I never did figure out. I rewrote the program (550 lines) and hit the deadline. I uncovered over 20 undocumented bugs. I wonder what it will look like 5 years from now. 

Everything I write new is either Javascript or PHP. Now that my startup is ramping up, soon I won’t have to deal with any of this old stuff any more. 

(Aside: I wonder how much production code in the world today is over 10 years old. And how much has been modified over 10 times?) 

10. The exact same code is in multiple places because you didn’t bother to put in into a common function. 

9. You have error codes in functions, but never bother to look at them (a sure sign that testing was never finished). 

8. You have early exits from loops because you don’t know how to properly code a recursion. 

7. You execute too much code because you don’t know the difference between “if” and “case”. 

6. You use 10 lines of code when 1 line would do because you don’t know any better. 

5. You need to run batch jobs from time to time to clean up your data base because you don’t know how to debug well enough to find what’s messing it up. 

4. A third grader doesn’t know what your variable names mean. 

3. You think “Third Normal Form” is paperwork you need to fill out for one of your 8 bosses. 

2. No programmer who has to maintain your code would ever want to work with you. 

1. Any programmer that has to maintain your code would be more than happy to accept the consequences of first degree murder. 

When it’s a house of cards. 

Perhaps I’m a little jaded, but I’ve built a very nice career rewriting software that never should have been written in the first place. Of the existing code I’ve encountered, at least 95% would never have passed a code review by me (or anyone else who knew what to look for). 

The problem is that we’re so committed to pass user acceptance testing that we never subject the source code and data base design to the same rigors. 

I like to think I’ve seen it all: one and two character variable names that mean nothing, homemade routines for sorting, selecting, you name it, memory leaks, iterations to nowhere, upward branches to nowhere, data base schemas that would make M. C. Escher jealous, and on and on and on. Face it, if programmers were doctors, we’d all be dead. 

As a constant victim of the “You Can’t Get There From Here Syndrome”, I often tell my clients the same thing, “It’s not how soon we get started, it’s how soon we finish AND how capable we are to handle the next revision”. 

Often rewriting is the last best hope. 

Today’s action items: 

- Give me a list of good (lifetime sales > $10,000) customers on the west coast (CA, OR, WA) who bought any product on the defective list during busy season (10/06, 11/06, 12/06) and haven’t placed an order since our last email blast. We’ll find out why. 

- Give me a list of phone numbers (using our Caller ID) of people who called in the last 4 days, whose call wasn’t answered and had never called us before. We’ll call them back. 

- Give me a list of our slowest moving (10%) products that haven’t been ordered in the last 4 months that are sitting in prime space (Location beginning with 1,2, or 3) in the warehouse. We’ll move them to pallets to make room for new stuff. 

- Give me a list of all products returned from Territory 7 in the last 3 months with a Problem Code related to fit or size. We want to make sure their description is correct on the website.

I could go on (and on and on)…

Just because something is old doesn’t mean it’s obsolete. Maybe because it works so well.