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?
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.
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.
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
"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.
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.
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.
- 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.
"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?
"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.
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.
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.
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.
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.
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,
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:
"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.