BUILDING PHILOSOPHY LIFESTYLE HABITS ADVICE CAREERS BUSINESS ENTERPRISE SELLING

It Takes 6 Days to Change 1 Line of Code

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)

For a programmer, 10 minutes = 3 hours

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)

Insidious Bug or Comedy of Errors?

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)

How do you collect requirements?

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)

How can clever software help customers?

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)

What's a minimalist coding style?

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)

How do you build something piece by piece?

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)

What does a programmer/analyst do?

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)

Programming FAQ

183 words

What editor do you use?

Textpad.

How can I learn to program?

(#95)

Are these things really that hard to do?

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)

Is becoming a lazy programmer evolving?

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)

How are we making this too complicated?

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)

Can waterfall planning work?

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)

What makes a programmer senior?

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)

Why are relational databases so important?

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)

Is software engineering dead?

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)

Why is BASIC still OK?

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)

When should you rewrite?

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)

How can you clean input data?

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)

10 Signs You're a Crappy Programmer

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)

Technical Debt

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)

Annoyances vs. Requirements

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)

What can be optimized?

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)

Why pre-develop?

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)

Documentation Belongs in the Code

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)

What's the best way to assign ID's?

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)

Why do you hate bad design so much?

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)

Why do you hate old code so much?

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)

What makes code crappy?

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)

How far should automation go?

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)

Tech books make you Good.  People books make you Better...
and
coming
fall
2017...
 
LERN
HOW
TOO
RITE
dont let bad riting hold u back
50 Documents
Every Programmer
Must Be Able to Write
ED WEISSMAN

All email answered.  edw519 at gmail
Copyright © 2017 Ed Weissman