ed weissman

Being told “how” instead of “what”. Use this API to access that database to do this process. Don’t tell me how to do something. Tell me what you want. Let me figure out how. That’s my job. 

Being told “what” instead of “why”. So you need a 4 GB csv download of the entire database every day at noon? Why? Oh, in that case, why don’t you just use which has been right at your fingertips all along. If you don’t understand the system, ask and I’ll be glad to help. But don’t make up unnecessary work for me. 

Being asked for data to put into your Excel spreadsheet which you will screw up 8 minutes later. Then you want me to fix it. Forget it. If you have a business problem, tell me about it. We will find a solution together. 

Lone rangers don’t get help. I’m not Tonto.

Calling me every 42 minutes for 3 days asking, “Is it done yet?” No, it’s not. I’ll let you know when it is and if there’s a problem, I’ll let you know about that, too. 

Not calling me for 3 weeks after a release. Either it’s working perfectly or no one’s using it. It would be nice to know which. 

Criticizing my work in a meeting in front of others without talking to me first. Big mistake. You don’t want to piss off your waiter and you don’t want to piss off your programmer. 

Meetings when a phone call would have sufficed. 

Phone calls when an email would have sufficed. 

Status meetings. Pointless. I’ll email status. Any questions, click “Reply”. 

Code walkthroughs that are more concerned with syntax than function. 

SQL SELECTs inside of iterations. Please go work at McDonald’s. 

Sarbanes-Oxley (SOX). 

1. Don’t sit on my desk. I’m a programmer. My desk is also my dining table. 

2. If I’m eating at my desk, don’t touch my food. I’m so busy that I usually bring what I think I’ll need for the day. I didn’t factor in your needs too. Go to the vending machine. 

3. If you come to my desk and see my typing furiously and I don’t look up, that means I’m busy writing code. If the building’s not on fire, go away and send me an email. 

4. If you get upset in a discussion with someone else, don’t raise your voice, don’t yell profanities, and most of all, don’t slam the door or throw anything. That’s when I leave for the day. Some of us have had enough of that for one lifetime. 

5. If we’re talking in my office, face me and take your hand off the doorknob. If it’s important, I’m not going to rush through it because you’re in a hurry to get somewhere else. If it’s not important, then leave me alone. 

6. If we’re meeting, turn off your cellphone. If it vibrates, don’t look at it to see who it is. If I’m not the most important person at that moment, then I don’t want to meet with you. 

7. I’m always happy to discuss important matters, but I don’t do status meetings. If you want to know status, email me and I’ll reply. Otherwise, my status report would read, Nothing accomplished. Spent all day in status meetings. 

8. If there’s cake in the breakroom, have a piece, but leave your Tupperware in your car. This isn’t Cheesecake Factory. 

9. Don’t lie to me. Ever. If you tell me that Joe agreed with these mods, I can easily confirm that with Joe. If he says you never talked to him, I will never listen to anything you ever say again. 

10. If you had Mexican for lunch, cut the rest of us a break and use the restroom at the Shell station. 

In enterprise IT, we have 2 kinds of vendors, those we actively embrace and those who hold us hostage. 

The biggest fear in making any major IT purchase is not the price, the conversion, or the change in culture; it’s the potential loss of options in how we run our own business. 

I’ve seen it over and over again: competitive pressure requires us to make a change in the way we run our business, but we can’t. For all kinds of reasons. The license agreement kills any possible ROI. We don’t have the needed IT support because so much of it is spent on keeping current. The systems don’t talk to each other. The feature we need is still 18 months away. And probably most of all, the software is not as excellent as we need it to be (let’s just leave it at that). 

Long gone are the days when you needed IBM’s permission to fart. Guess who the biggest culprit is today? 

Just because you go with someone doesn’t necessarily mean you like it. Almost every enterprise IT department I know would love an alternative to Microsoft. (And make no mistake about it, the enterprise is Microsoft’s strength, much more so than the consumer.) 

Sure, pissing off your customers may pad today’s bottom line. How do you think those customers will feel when your landscape changes and they have more choices? 

[Entered using ie7 on xp pro. I didn’t have a choice.] 

Yesterday I was up to my earlobes implementing a business intelligence/data warehouse system in a very large SOX-compliant enterprise :-). 

For current requirements, this solution is excellent. It is third party software, installed on top of an existing ERP system, that enables the users to extract whatever data they need and build their own reports without submitting a ticket to IT. Everyone loves the prototypes and is dreaming about the possibilities. 

So instead of beating up on enterprise life, let me just share a little bit of yesterday, one typical enterprise day: 

- A 3rd party build just stopped at 98% complete with no error message. 

- Another build crashed with error messages I had never seen, so I had to open another ticket with our vendor 

- We ran out of disk space on a volume we didn’t know the software was using. 

- I had to add additional data cleaning functions to remove heretofore unknown control characters in the enterprise data. 

- I inadvertantly named 44 files with the vendor’s own naming convention, so now no one can tell whose files are whose. We had to reset our standards and rebuild. 

- Although this vendor has hundreds of installs, oddly, none of them are SOX compliant. The controls, audits, and duplication of data needed will more than double the resource requirements. Worse, I’ll have to do an implementation that no one has ever done before with this software :-) 

- Today we start writing our own tools to handle the SOX compliance and satisfy the auditors. Some fun. 

I can go on and on. You get the idea. And I haven’t even touched upon the usual enterprise culprits: the meetings, the politics, and the lack of project management. It kinda sucks to have to do triple work to get the same thing done. 

So whose fault is all of this? No one’s. That’s just the way it is. Every time I think of a better way to get things done in a large enterprise, someone has 5 good reasons why they are the way they are. It’s wasted energy fighting that. 

As a business programmer, I’ve worked on quite a few things where there is much more at stake than just money. Just a few of them:

- scheduling & routing of ambulances and firetrucks 

- scheduling & routing of trucks carrying time-sensitive medical supplies 

- clean-room quality control of medical devices 

- distribution of pharmeceutical formularies 

- medical claims processing & adjudication 

- formulas & recipes for large batch food processing 

- medical demographic databases of allergies 

- distribution of mission critical airline parts with linked certifications 

- certification of automotive safety devices, including airbags 

- building contractor specifications, including electrical & plumbing 

- clinic scheduling 

Just because something won’t hurt you immediately doesn’t mean that it can’t hurt you “eventually”. You can see from my examples that so much we program does affect the welfare of many, even if indirectly. 

We really have reached the point where software QA is just as important as engineering QA. We programmers aren’t the only link in the chain, but we are an important one. 

I have looked at horrendous enterprise code that supported critical health and safety issues and thought, “Do you really want to get on that plane?” or “Are you sure you want to take that pill?” (Hopefully QA catches most of the potential culprits.) 

Thanks for getting us to think about it a little more. This sort of thing should always be on any good developer’s mind. 

A customer recently asked me to look into a program that used to run in 5 minutes but now took 1 to 4 hours. It’s used by thousands of people all over the world all day long. 

It iterated through an array doing 3 SQL SELECTs against non-indexed files for each element. There used to be about 50 elements in the array; now there were more than 5000. I rewrote the whole thing in one day to do a total of 4 SELECTs and run in 12 seconds. 

But it took 6 days to get through QA (while the users continued to suffer). QA’s biggest complaint? I indented 4 spaces instead of the (unpublished) standard of 5 spaces. 

Of all the things I have to deal with, nothing pisses me off more. Software QA is becoming more and more like TSA security at the airport: illogical, and obviously so. Last year, flagrantly unacceptable code was promoted without question while its replacement was held up on a meaningless detail. 

We programmers are a funny lot. Make us struggle for business or technical reasons and we adapt beautifully. Make us struggle for something stupid and we just get pissed off and do something else. What a pity. 

I remember a project I worked on in a large enterprise years ago. All of their systems, believe it or not, were batch. Inventory, accounting, order processing - all data was entered into hold files, or worse, filled out with pencil and paper and turned into keypunch. All databases were updated in a large batch overnight. (Today, it’s hard to believe anyone ever did that.) 

Our project was to migrate all apps to a new real time package. They spent millions of dollars and when it was all done, the controller complained, “Who decided that we needed real time Accounts Payable? Why would we ever want to pay our bills “faster”?” 

No one had ever asked that question before. No one even thought about it. We had spent $1 million on a module nobody wanted because IT decided it. Eventually he added procedures to continue to fill out all accounts payable transactions with pencil and paper and enter them into the on-line system at the end of the day. What a waste. 

Same argument here. Some things you want faster. And you’re willing to pay for them, one way or the other. But other things should just stay the way the are. 

Some things never change: you actually have to “think” about your apps before you implement them. 

ERP has deep roots.

The original acronym was MRP, Material Requirements Planning, a perfect candidate for business software. It answered the question, “If I need to deliver 9 helicopters on these 9 dates, then what components will I need on which dates?” Believe it or not, this was all hand calculated at one time. 

MRP was very complex and difficult to implement because it required absolute precision and discipline, rare back then and still rare today. If your base data (inventory balances, lead times, quantities per, etc.) were the least bit off, the resulting automated explosions would be way off. So an industry of software vendors and consultants was born to attack all of these issues. 

The problem with MRP was that it didn’t work well at all for products with few components but complex processes, (think chemicals, energy, distilleries, food processors, etc.) So CRP, Capacity Requirements Planning was born to plan and manage factories with high capital expenditure requirements. (It doesn’t matter if we have exactly the components we need if we have nowhere to work on them.) 

Before you know it, “everyone” wanted in on the act of expensive software and consulting, even in disciplines that didn’t require them (why should SAP make all the profits). So along came accounting, sales, HR, and everyone else, and now we’re stuck with ERP, a cow that’s ripe to be milked for a long time. 

“Aren’t There Real Problems To Solve?” 

I have always spent a lot of my time in small or midsize companies (10 to 200 employees), and I can assure you the answer is ABSOLUTELY. 

These are hard working people who are in a different world than most of us. They don’t facebook, twitter, or IM at work. But they are unbelieveably busy trying to get things done while depending upon software and systems that most of us here would laugh at. 

Many of them don’t have time to get to all their emails and voice mails. They have to make snap decisions all day long without enough information because their software just doesn’t give them what they need easily enough. They have constant problems with interpersonal communication, instruction, and understanding. 

Just a sample of what I’ve witnessed in the past 3 weeks: 

- We need multiple “ship to” addresses for this institutional customer. The software doesn’t support it. 

- The exchange server is down. 

- We need multiple prices for the same item, depending on the scenario. The shopping cart won’t allow it. 

- 300 “smart part numbers” were configured incorrectly because no one gave Jane the correct Vendor Codes last week. But now, we have orders, inventory, and history for those items, so the software won’t let us change or delete them. 

- The exchange server is down. 

- No one remembered to reset the warehouse server last night, so everything came in today with the wrong date. 

- The new stockroom printer doesn’t support HP PCL, so the bar code labels are all wrong. 

- We think that $90,000 order acknowledgement from XYZ Company was deleted by the spam filter, but we’re not sure. 

- There was a bad pointer in the UPS data base last Tuesday, so 72 packages all went to the same customer in Duluth. 

- The wrong 800 number is being printed on our invoices. Our customers are calling a sex hotline. 

- The exchange server is down. 

These are not jokes. I see them all the time. And while we regale all the cool stuff WE are doing, I can honestly say that the situation in many small businesses hasn’t improved all that much. And there are 7 million of them. They need help. 

The good news? This is a fantastic opportunity for those with our skills and technology. 

Yes, there are plenty of real problems to solve. Stay tuned. 

I just converted a client OFF of a major enterprise package to something 20 years OLDER and much easier to use. Frankly, I was stunned to see how difficult it was to use and how poorly it was designed. 

Examples: Even though it maintains 160 columns for each Order Header, “Time Entered” is not one of them. So go ahead and try to schedule a call center with no Time Of Day history. To review a single customer’s history (and presumably answer their questions while they’re on the phone), you have to open up 6 different windows! 

My general suggestion: Write a “Test Drive” based explicitly upon your client’s business. Have them enter an order and take it through every stage of it’s life (reserve or commit inventory, print, pick, ship, confirm, bill, collect, post, etc.) The test drive should also hit every function needed to do this, setup a customer, SKU, GL Chart of Accounts, etc. Then have the appropriate person working for your client do their job on that system.

DO NOT touch the mouse or keyboard. DO NOT let the vendor touch the mouse or keyboard. 

If they can’t enter, ship, and bill an order in a couple of hours with less than one day’s instruction, eliminate the system and save yourself a lot of expense and headaches down the road. 

Naturally, most sales people will object to this approach and use any tactic to avoid it. Make it clear to them and your client that this must be the plan. The test drive method is infinitely more effective than the old RFP approach. When the poor systems are clearly failing the test drive, the saleman may object with questions like, “Are you going to train your people or not?” which you’ll calmly answer, “Not if it takes until 2018.” Good luck.