689 words

(A true story.)

Philip (President): Our factory is underutilized by 10%. Either we start building more of our backlog or we lay people off. I'd rather keep everyone busy, build inventory, and get ahead of the curve before the busy season. How can we do that?

(#255)

1100 words

10:48

Boss: Hey Ed, Sue in Detroit says that sometimes the wrong Invoice Part Number is showing up on the Product History Screen. Can you help us figure this out?

(#254)

1130 words

A client presented me with a big problem that required immediate attention. I worked on the problem and helped them solve it. Along the way, I discovered a whole bunch of things that needed further examination by software developers.

The names and facts are changed and I will present the code as pseudo-code. I won't compromise client confidence and the technology doesn't matter. This could have happened anywhere.

(#251)

375 words

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.

(#100)

306 words

Just a few off the top of my head:

1. As part of the research for requirements for a new inventory package, I noticed that every pallet was counted by 3 different people and the lowest count was recorded. I worked with plant supervisors to fix the procedures. Management then realized that there was now no need for new million-dollar software. They rewarded my effort and concern for the company with lots of great project work and money. Lesson: Look for the obvious first.

2. A user asked me to help solve her forecasting problem. The two of us sat down and designed the software to do it. I realized there was a parallel effort to do the same thing in another division (with an expensive purchased package), so I made my software work for both divisions. It took 3 weeks to write and people were very grateful. I was employee of the month and got a nice bonus. Lesson: Sometimes little things can solve big problems.

(#99)

225 words

"A minimalist lifestyle does not make you a better person"

But a minimalist coding style does make you a better programmer.

I really don't mind a few extra Philips screwdrivers, kitchen knives, or pairs of shoes in my house, but I every superfluous bit of code in my repository drives me nuts.

(#98)

247 words

I love how everything has a fancy name now. We've been doing StartInTheMiddle / MinimumViableProduct / Prototyping / GetSomethingOut / StepwiseRefinement for years:

Customer: I must have anything I want from the database without asking you.

Me, 1 hour later: No problem, here's your screen.

(#97)

252 words

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

(#96)

183 words

What editor do you use?

Textpad.

How can I learn to program?

(#95)

507 words

"I have not seen these things be successful, therefore they can't be successful".

This kind of thinking scares me, not so much because it's so myopic, but because it becomes a self-fulfilling prophecy: "I have never seen success" becomes "Success is not possible" which becomes true because we stop trying.

Mere mortals throw up their hands in futility, blaming the user, the state of the art, or the alignment of the planets, without ever understanding the fundamental principal that great systems accommodate great needs and the greatest need of all is constant change.

(#94)

157 words

Show me any tool and I'll show you a horrible use of that tool. That doesn't make the tool horrible.

ELSE statements don't kill. Drunk programmers kill.

This reminds me of something I once ran into:

(#93)

361 words

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.

(#92)

233 words

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 analysis. 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.

(#91)

224 words

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

(#90)

198 words

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.

(#89)

426 words

"Software Engineering is Dead" is obviously an overly sensational title, but let's look for the deeper truths.

First a little background. I have built a career developing business applications as a contractor, often in very large organizations. I am almost always very successful and I'm often regarded as a hero doing what most people here would call "just doing my job".

Why is it so easy to be a hero in the enterprise with software that would just seem ordinary in other places? Is it because enterprise programmers aren't as good as us? Is it because their managers are all PHBs? Or because they don't know how to run projects?

(#88)

220 words

"It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration."

For what it's worth, I have written over 1 million lines of BASIC for over 100 customers, most of it still it production, and all of it doing important work producing goods, services, and jobs in so many uncool industries we couldn't live without.

Maybe I'm an outlier, but I have gone on to learn algorithms, dynamic programming, database theory, client/server, and web development. I believe the elegant simplicity of BASIC and database theory, although limited in application, has provided an excellent base upon which to build.

(#87)

198 words

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.

(#86)

94 words

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

(#85)

199 words

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.

(#84)

150 words

Typical way that competent developers end up with technical debt:

1. Customer/user/consumer has a vague idea of what they need but doesn't know how to express it.

2. Developer works with customer to learn their business and understand their requirements.

(#83)

247 words

"One of the annoyances that we have to deal when building enterprise applications is the requirement that no data shall be lost."

Since when is a business requirement an "annoyance"? We keep data for lots of good reasons. Just a few off the top of my head:

- IRS requirements

(#82)

192 words

I've always thought there were 2 types of things that could be optimized:

1. Things that need to be cleaned up.

2. Things that never should have been written in the first place.

(#81)

262 words

"I've never seen anyone able to design something away from keyboard that doesn't change significantly once it's written"

It does change once it's written.

The idea is to get a clear work plan on a "close enough" design. I estimate that my first cut of anything is maybe 50% or so.

(#80)

313 words

The advice from this post is exactly what you'd expect in theory and exactly "what not to do" in practice. For one simple reason: the source code is (hopefully) the only thing pretty much guaranteed to survive.

I have seen countless shops where valuable history was lost because it was stored on someone's c: drive, a network drive, or some repository that failed to survive some kind of migration. And even if these other files (digital or paper) did survive, chances are that the programmer that needed to see them never did anyway.

Good shops practice keeping audit trails "in the source code". This means good commenting. Which means good code review and quality control.

(#79)

434 words

The "Name" issue isn't that much different from the "SKU" issue. (SKU is short for Stock Keeping Unit, aka Part Number or Product Number). I have had to deal with this everywhere that has SKUs. No one does it well, but by slowing down and thinking about it, there's almost always a decent solution.

There are 2 ways to assign SKUs, sequentially (start with "1" and increment 1 for every new SKU) or not sequentially. I have never seen anyone do it sequentially. (Although some excellent systems keep 2 SKUs, one of which is sequential and is used as the primary key and for all indexing. This is the best way I've ever seen to handle SKUs that change, but that's another story.)

Almost everyone wants a smart or semi-smart SKU. So that by simply looking at the SKU, anyone can tell what it is without reading the description. You know, the first digit is Commodity Code, 1 for shoes, 2 for pants, etc. Then another digit for color, another for size, etc. This works well until you have ten colors; then you need 2 digits or alphas.

(#78)

430 words

Bad design is everywhere:

My old microwave oven had one control, a dial. Just put the food in and turn it. The whole dial represented 12 minutes, so just estimate how far to turn it. My new microwave has 22 buttons. I forget which is which. I have to turn on the lights and get my glasses.

The previous owner installed vertical blinds on the double hung windows. Think about that. Impossible to have open windows without endless noise and movement.

(#77)

229 words

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,

(#76)

281 words

When it comes to maintaining code, I believe there are 2 kinds of crap: subjective (I don't like it) and objective (it's crap because of these 14 specific reasons).

You're probably right about people who inherit my code. I know, when they've whined about it, I confronted them. "Please show me exactly what's wrong with it. What are your specific complaints about violations?" I rarely got an objective answer. It was usually something about formatting, indenting, variable names too long, variable names too short, I'm used to it the way we did it (wrongly) at XYZ Co., something like that.

True crap can be objectively identified by a violation such as:

(#75)

175 words

"Weak human + machine + better process was superior to a strong computer alone and, more remarkably, superior to a strong human + machine + inferior process."

I had to read this statement 3 times before it hit me: What's true in chess is also often true in business. A little background:

I recently wrote a forecasting system for a company that processes 7 million orders per year. Worse, this company was the merger of two other companies, each of which did forecasting differently. One had a very expensive Oracle based "strong computer" that calculated almost everything and told the planners exactly what to do. The other just dumped data into Excel files and teams of "strong humans" manipulated them until they intuitively worked out the best plan. Neither team could believe the way the other team worked.

(#74)