- A CIO who isn't compatible with the central office
- Concerned about automating programmer jobs?
- What's needed to be effective
- Last shot at tough CEOs
- Defending tough CEOs
- When fun isn't very much fun
- Another look at exit interviews from the interviewee side
- IT as profit center
- A developer who can't install, or connect
- Making the case with central IT
August 31, 2007 | Comments: (0)
A CIO who isn't compatible with the central office
Dear Bob ...
I'm not really looking for advice. Or maybe I am, if you have any.
My management style, if you will, was considered completely unacceptable by our Corporate Office. I have since been in a "lengthy transition" so that they can rid themselves of my influence and bring on a new IT Manager who is a bit more, ohhh, let's say, conformative - without losing the brain trust they so desperately need.
I have the distinct feeling that my particular breed is dying quickly here. It's truly a shame.
- Vanishing
Dear Vanishing ...
Well, you sort of asked for advice, and since I'm in the advice business …
In your situation, one of two conditions was possible. It's probably too late at this stage; if so, take this for what it's worth:
Either there's an approach to running IT that works for both you and the corporate office, or there isn't. From your brief description, I'm guessing the folks in the C.O. didn't have a lot of interest in spending time with you to figure out what that might look like. That put the ball in your court.
I'm not a big fan of lengthy transitions. It was up to you to work with the C.O. to either figure out how to make things work or to make other arrangements for yourself. I doubt you'll look back at the transition period and consider it one of the more rewarding times in your career, after all.
And, from a career perspective, so long as you work for them they are your customer - they make the buying decision about the services you personally deliver (which is to say, they decide to pay you to run IT for them).
So in the end it's like any other supplier/customer relationship. Their responsibility is to make clear what they want you to deliver. Yours is to decide whether you're interested in delivering it.
It sounds like you've already been through that thought process and have decided you aren't. So my advice is to implement that decision. That doesn't mean resigning right away. It means accelerating your search for a more compatible customer.
- Bob
Powered by ScribeFire.
Posted by Bob Lewis on August 31, 2007 05:31 AM
August 29, 2007 | Comments: (0)
Concerned about automating programmer jobs?
I just had to comment.
In a recent Ask the Headhunter ("I, Programmer," 8/23/2007), my friend Nick Corcodilos worries about Gordon Morrison's "new" approach to software development: Use more automation to write code. In other words, no more programmers.
I put "new" in quotes because in the context of information technology, 25 years counts as ancient and this notion qualifies for the adjective. It reappears every so often, sometimes succeeds, doesn't eliminate programmer jobs, and goes away again.
For awhile.
Anyone who thinks this is a new idea has never read one descriptive word about Delphi, Forte, or for that matter Microsoft Access (I'm deliberately mentioning only frightfully old examples). Developers drag visual objects around and the integrated development environment (IDE) does the rest. Or at least most of the rest; sometimes the developer does has to write code to fill in the gaps.
In the end, it's barely possible that Morrison has developed a Genuinely New Idea. If he has, it still won't eliminate the role of software developer - it will merely eliminate a few more of the most mechanical tasks.
It's been at least twenty years since the best developers have been those who can squeeze a few more milliseconds out of execution time. The best developers are the ones who can translate what the business is trying to accomplish into what computers can do.
Perhaps Morrison really has gone Holy Grailing and returned with a magic compiler that can intuit what business managers and users really want the software to do, even when they themselves aren't entirely sure until they talk it through with a professional.
In an infinite universe, everything must happen somewhere at least once. If I had to play the odds, though, I wouldn't bet that the magic compiler has happened here, on this planet, just yet.
- Bob
Powered by ScribeFire.
Posted by Bob Lewis on August 29, 2007 06:14 AM
August 28, 2007 | Comments: (0)
Dear Bob ...
From your most recent column ("More bridge lessons," Keep the Joint Running, 8/25/2007):
<snip>
Here's why it's relevant. Your job isn't to be right about all of this, then to say I-told-you-so when something goes wrong.
It's to establish strong enough working relationships throughout the business to be persuasive, to communicate risk and its consequences accurately enough to prevent its turning into reality.
Much harder.
</snip>
What does one do when they are the lowest level person in the organization, and the warnings fall on deaf ears? I was the schlub hired to restore the fallen servers, and do the cut-overs on the weekends.
A full blown analysis complete with evidence take from the Manufacturer (the bozos who just changed their ticker symbol) and LOTS of rants from admins across the world, resulted in nothing.
I decided to cut and run. Maybe a career killer, but my health was more important to me than the family's earnings.
Was there a better way?
- I told them so
Dear Teller ...
What should you have done? Without more detail it's hard to say. In general, the right answer is, your job … which includes making sure your boss and your boss's boss are informed regarding root causes and future risks. Once you've informed them, as it appears you did, your responsibility is to continue to do whatever work is assigned to you and to do it well.
That leaves out a common scenario, which is that you continue to be scapegoated for every server failure even after you've explained what needs to be done to prevent recurrences. That happens a lot in corporate America. Under those circumstances you have these choices:
- Inform your boss's boss's boss, letting your boss and your boss's boss know you're doing so. This is the honorable course of action. Usually, it's also career suicide. Choose this course of action if your assessment of the character of each of the three individuals says they'll take it positively.
- Make use of your company's open door policy to inform your boss's boss's boss without informing the rest of the chain of command. If that individual is politically savvy, he/she will create a situation where you can provide the right information publicly without doing yourself damage.
- Do your job, accept the scapegoating, and develop a thick skin.
- Find a better job in a company that would rather fix problems than assign blame.
- Bob
Powered by ScribeFire.
Posted by Bob Lewis on August 28, 2007 08:44 AM
August 26, 2007 | Comments: (0)
Response from the CEO responsible for "Defending tough CEOs," Advice Line, 8/22/2007:
Well, seems we disagree. I don't condone, I don't defend. What I know is that top performers need to be and are READY for the grist mill of working side by side with the CEO.
If there are people intimidated by their CEO, then they should leave. End game is a CEO who does not balance his performance and emphasis on success, as well as failure, with his relationship dynamics will not be long for CEO. It is just the ecomonics of it all - free markets at the granular level: s/he acts like a jerk; net is lost perfomance and dents to the bottom line... s/he will be replaced... and not always with a cushion attached to his/her derriere. It is hard to lead when the team fails. And it is usally failure that precedes frustration.
As for advice, perhaps you should write a piece from the other perspective. That is, when the expectations of the leader are not met, what stress s/he experiences ... One hires right-hand men and women to DO the job.
These people are - or need to be - tested, tried and true. When those you rely on disappoint, through faults and flaws of their doing and execution, it is not time for a staff development session between him/her and the CEO. It is SERIOUS time, and some CEOs show their frustration in ways that you and I don't like or would ever consider as actions of our own.
But I will tell you this, like it or not, I have been patient and I have been painful in how I react, and I expect the boys and girls to "get it," and they do. It is the total relationship that matters, not the explosion or the euphoria. So delve on that side a bit and consider when leadership does not fail, but some of those being led, do.
Bob's last word:
It appears we're doomed to half agree. Any CEO who makes the working environment a grist mill is, to my way of thinking, a poor leader. I also recognize that I have to make room for exceptions. The world has a history of characters who are tough to work for but have enough other redeeming characteristics that it comes out okay in the end.
I'll certainly think about the topic you suggest. I write for a leadership audience, and figure anyone who wants those reporting to them to accept responsibility first have to demonstrate the trait themselves. As a result, my usual fare is about what leaders need to do better, which includes what they need to do better when those reporting to them don't work out. (Answers: First, make sure success is possible, and that the definition doesn't change with the leader's mood. Then, coach if possible, replace if necessary, and hire better next time.)
Since that's my audience, I'll have to find a way to frame your suggestion so it's useful and appropriate for them. Thanks for making it.
- Bob
Powered by ScribeFire.
Posted by Bob Lewis on August 26, 2007 02:56 PM
August 22, 2007 | Comments: (0)
Dear Bob ...
I was surprised that you even bothered to comment on that letter ("How to deal with a really bad CEO," Advice Line, 8/8/2007) for advice.
People want to play close to the heartbeat but can't stand the thumping sound - get over it. Things sometimes get harsh and, well, disagreeable when you're in that zone. Someone throws chairs, another threatens "Your job is gone before mine!"
CEOs are not in that position to be nice, nor are they there to be cruel, they are there to do a job, produce results, perform. If they don't, they're gone. I agree with you, if you can't take it, leave. But my guess is people who have the self esteem and the assertiveness necessary (not aggression) can both work with this guy and get him to back off a tad - but it is FIRSTLY the person's responsibility, not the CEO's. Thanks for the listen... and yes ...
- I am a CEO.
Dear CEO ...
If you're a CEO and you defend your peers who throw chairs, I think you need to learn more about your responsibilities as a leader. Your job is to get results. If you think you can achieve better results by bullying the people who work for you, you're getting only a fraction of the results possible.
It's like this: If the people who work for you are afraid of you, they'll tell you what they think you want to hear, not what you need to hear. That makes you worse than ignorant - it makes you misinformed. Leaders who are misinformed make bad decisions for reasons that I trust don't require additional information.
As a leader, the definition of your job is to produce results through the efforts of those who work for you. Leaders who yell, throw things, and intimidate end up having second-raters working for them, because first-rate employees have no reason to put up with that sort of treatment. They don't have to.
And the second-raters who are left aren't going to deliver first-rate results.
Probably, that's going to make the sort of CEO you describe throw another chair.
- Bob
Powered by ScribeFire.
Posted by Bob Lewis on August 22, 2007 06:58 AM
August 21, 2007 | Comments: (0)
Dear Bob ...
You may not be full of beans on this one ("Fun for fun and profit," Keep the Joint Running, 8/20/2007), but you're close.
Our company has a policy: Win and have fun. And a lot of managers I know try to follow it. We have quarterlies and team builders, management doesn't have a problem with us spending a reasonable amount of time doing fun things, etc. In other words, they really do encourage fun (within P.C. limits, of course, but that's understandable).
And the morale just keeps sinking.
I'd a billion times rather have management that provided a rewarding work environment than management that promoted fun. I'd FAR rather feel that the company was fair in recognizing and rewarding good workers than feel like I'm being bribed by "fun" things. ("Oh, sure, Bob X got promoted to VP because he's a "good ole boy" and part of the inner circle, when hard-working Larry Y deserved it a lot more. But hey, you're getting all these fun things, so what are you complaining about? You just have a bad attitude!")
This used to be a great company before our old CEO retired. It's been steadily going downhill ever since; ask just about any old-timer here. I used to be proud to work here, now it's not much different than working for the government, except more permissive. I'm still here because my personal workgroup is good and my job is interesting, but I'd bail in a minute if the right opportunity came along.
Fun is icing on the cake, but it sure doesn't make up for lousy-tasting cake.
- Having fun and hating it
Dear Fun-lover ...
You make an excellent point. Fun isn't supposed to be a substitute for the desire to win. It's supposed to augment it by keeping the environment loose and creative instead of tense and fear-driven.
As always, balance is the key. Too much fun and employees take their eyes off the ball. Not enough and they're more likely to bobble it.
And as you point out, losing isn't fun at all. Which brings up a question for which I have no easy answer: Whether it's possible to maintain a level of intensity without losing the sense of fun.
Here's one possible answer to the conundrum: Fun might not be the best solution for every work environment, or for every situation in every work environment. In fact it certainly isn't. Imagine a bunch of Navy Seals on a mission, having fun every step of the way. Unsettling, isn't it?
But remember, as I carefully defined the term, "fun" is about creating an enjoyable work environment, not an amusing one. The point is that grimness discourages creativity, depresses energy, and in many other ways causes a company to lose.
- Bob
Powered by ScribeFire.
Posted by Bob Lewis on August 21, 2007 05:40 AM
August 17, 2007 | Comments: (0)
Another look at exit interviews from the interviewee side
Dear Bob ...
I've been out of work for 7 months, now, and I'm wondering whether it is because I did something I thought was reasonable and moral.
Just before I was about to leave, I found out that our IT Manager had been slipped in by the Supreme Court. OK, not really but...
There were two people in the department when I joined the agency. A senior member who had been there early on (about 5 years) and had run most of the cabling, etc., and another guy who had been there about two years. The later was the pushy type, the former, just got the job done.
Upper levels thought that we needed an IT Manager as they wanted to move the current person, who carried the Quality Management title, upstairs with them.
They posted the job, as required by law I'm sure, one day before the senior guy went on vacation for 2 weeks, and closed it before he got back. The newer guy got the job, of course.
When I wrote my bye-bye letter I mentioned this as one of several problems that I had seen.
My exit interview was done by the Manager's boss, who was quite indignant as he had been the one to set this up. "It was perfectly legal, he just didn't see the posting". Of course, if you're not looking for a job, you don't check that stuff often.
He's the sort who thinks he is above everyone. I thought that the deal was "immoral".
Anyway, after he had retired, I applied for a couple of jobs there, including one as specialist on a particular piece of software that I knew quite well.
Never heard a thing.
Your thoughts?
- Exit interviewed
Dear Exited ...
It very well could be that your former employer's lack of interest in your services is connected to your exit interview. So the answer to your question is yes.
This goes back to a piece of advice I've given before: When it comes to honesty in an exit interview, the personal risk greatly exceeds the personal payoff. This can be proved mathematically. The personal payoff almost always has a financial value of $0.00. The risk of personal harm from being honest is greater than 0%. The value of the personal harm experienced should the risk turn into actual events is significantly greater than $0.00 (it might be the reason you've been out of work for seven months).
Therefore, the expected value of the risk is greater than $0.00 while the potential benefit is $0.00. The costs exceed the benefits.
There are exceptions, of course. If you genuinely like and trust the company you're leaving and the people who work there, have comments that are constructive in nature rather than critical and issue-based rather than being about individuals, then there is some potential benefit to you in the form of leaving good feelings behind you.
That clearly wasn't the case in your exit interview. You criticized the actions of an individual. No matter what other result came from your doing so, you probably branded yourself a troublemaker. Now it's coming back to haunt you.
- Bob
Powered by ScribeFire.
Posted by Bob Lewis on August 17, 2007 01:13 PM
August 15, 2007 | Comments: (0)
Dear Bob ...
I would like to raise a topic that needs to be considered in this rapidly growing age of technology.
I'm interested in the trend most companies have about making IT Departments an income rather than expense unit. The reason I want the issue raised is that many of the IT developments now are profit-making entities for the company. For instance, a financial institution can attribute much of its profits to IT teams that develop products such as phone banking, online banking, and so forth.
Have you heard much mention of this or know companies that allow IT units to be profit instead of liabilities? If so, can you share some articles and facts surrounding this?
- Profit-minded
Dear Profit-minded ...
I have covered this topic from time to time (I think). It's usually implemented through the mechanism of "transfer pricing" - what used to be called "chargebacks" until some clever consultant decided he or she could charge more money advising on transfer pricing because it sounds more sophisticated.
A couple of past Keep the Joint Runnings you might of interest are "The value of an enabler," (2/10/2003) and "Who's your customer now?" (2/28/2005).
It comes down to this: Businesses can decide to make IT and every other internal service department profit centers. Doing it well is an interesting academic exercise. The supposed value comes from making everyone responsible for the costs they drive by charging them for those costs, just as if they were to purchase the same services from an outside vendor.
It looks great in the PowerPoint, and it generally works the way so many PowerPoint concepts work - perfectly, except for the unintended but easily predicted consequences.
It isn't all that different from trying to cure a disease by feeding poison to the patient. The poison kills the germs, just as it's supposed to do. That it also kills the patient falls into the category of "oops!"
In this case, transfer pricing drives the creation of heavily-walled political silos, the mis-handling of corporate overhead, messy technical architecture through inappropriate outsourcing, and the complete loss of ability on the part of the enterprise to act as a single entity with a single purpose.
Here's another way of looking at the issue: Some businesses have figured out that accounting reports provide only an incomplete picture of the health of the enterprise. They implement "balanced scorecards" to give them a more complete view of things.
Companies that try to turn every department into a profit center through chargebacks figure the opposite: If they're only clever enough, they can use their accounting system as the sole means for understanding, not only the health of the enterprise, but also the health of every component of the enterprise.
Call it the fractal theory of management, fractals being the branch of mathematics dealing with structures that look the same at all levels of magnification. My opinion is that it's an attempt that mistakes cleverness for wisdom.
- Bob
Powered by ScribeFire.
Posted by Bob Lewis on August 15, 2007 09:11 AM
August 13, 2007 | Comments: (0)
A developer who can't install, or connect
Dear Bob ...
We're going from Novell (dead end) to ActiveDirectory. And even as a developer (mostly Unix, but some PC), "they" want to lock down my desktop so I can't install apps (not even give me a login I can switch to to do the installs, and switch back).
But, wait! There's more! I get a second computer to do development that isn't on AD so I can do installations.
I maintain an app that has data that should be secure. But I have to work on it on an insecure desktop. I know this security thing is rough, and I don't know all of the things going on, and I know they have a mandate from the big boss, and I don't envy their decisions, but sometimes I scratch my head. Is this suboptimizing the parts to optimize the whole?
- Suboptimized
Dear Sub ...
No, it's just strange. Or maybe there's a budget problem. The way I learned it, IT creates development and test environments that replicate production. What I'd think you should have is a development desktop system, connected to the development network, which includes the development copy of ActiveDirectory and lets you install software.
But I'm not there and it's easy for someone as far away as I am to spout off. Perhaps there are good and valid reasons for setting things up the way they are.
- Bob
Powered by ScribeFire.
Posted by Bob Lewis on August 13, 2007 09:57 AM
August 12, 2007 | Comments: (0)
Making the case with central IT
Dear Bob ...We are a small group of dedicated people working for a public safety unit under a large agency. We have accomplished the impossible and have worked in an environment of hostility towards the public safety department by other support units. There is central IT at six of the agencies and we fall under the HQ agency. Our relationship with HQ IT has always been difficult as our needs do not always fall under their standards for business operations. We are a 24/7 operation and require vertical applications and processes that relate to law enforcement.
Our staff is well versed in the specification, implementation, and support of these unique systems and we have been successful over the past seven years. At this time, we're undertaking a migration to an entirely new system that will replace most of our bread and butter applications, move from Nortel networking to Cisco, from Novell and GroupWise to Windows and Exchange, and introduce modern law enforcement systems. The training will be considerable and our group has been working on this project for three years.
We have requested that our staff be increased – finally – to best support the new systems and to accommodate new staff that has doubled since 2001. The HQ C-level staff has determined that the HQ IT staff should be directly responsible for all of our systems and the process has started with knowledge transfer and giving up our projects. This group has not been involved with the project, has limited knowledge of law enforcement systems but the CIO insists that with "good" SLAs, anything can be accomplished. With seven years of historically bad support, it's difficult to accept this change.
The HQ culture and work ethic is very different from what we've developed in our department. There is a strong case to grow our technical unit and to continue our future support. My questions are "how can I best develop a case and objective study to demonstrate that our department's needs are best met with dedicated staff?" and how can I influence the C-level managers to consider this case? Hiring a consultant to perform this on our behalf will be thwarted by central IT so that is a distant option. Any comments would be helpful.
- Case builder
Dear Casey ...
I don't think you're going to like my answer.
First, give up on the notion of winning the debate by making a strong business case. This issue isn't being decided by evidence and logic. From what you describe, at least, the chain of argument goes like this: "Here's what I want the answer to be" -> "Here's a plausible sounding statement that rationalizes the decision for me, and is good enough to shut off the argument from anyone else" -> "Stop arguing - I've made my decision and it's final."
You have two avenues to explore that I can see. One is to present an alternative that sounds a lot like what the HQ CIO has planned but gets you what you really need. It might go something like this:
* After everyone agrees to an SLA, it's still true that the more users you have to support, the more people you'll need to support them. The two questions are, how many additional support staff are we talking about and where will they sit?"
* We already have the local infrastructure set up and know the territory. Why don't you plan on seating however many you're planning to hire in our area?
It's a long shot but it might work.
The other alternative I can think of is to match clout for clout. Surely, the thought of having HQ's IT staff providing local support is making the top managers in your area nervous. If you have a good relationship with them, explain your concerns, let them know you don't have any influence over the decision, and suggest that it's up to them to make the case for local support if that's what they prefer.
There is, of course, a third alternative, and it isn't all that bad: Let things play out. If you're right, one day there will be a blow-up. When it happens, your hands will be clean and the HQ CIO's fingerprints will be all over the crime scene.
Then you can make your case to whoever is in a position to recommend a change of course.
- Bob
Powered by ScribeFire.
Posted by Bob Lewis on August 12, 2007 09:45 PM
August 08, 2007 | Comments: (0)
How to deal with a really bad CEO
Dear Bob ...
I have some understanding of being demeaned while at work. My boss, the CEO, likes to play games with his employees. He will put them in a position so that he can use them to get something done for him and then he pulls you out of that high position and puts you in a smaller one and then after that nags at you, intimidates you, threatens you until you quit as he is through with you and don't need you anymore. It blows my mind on some of the stuff that he does.
I was covering for his Assistant one day, it was the final day, Friday, and I forgot to take his mail down. He came into my office and started chit chatting about his assistant and if I thought after having all this time off if she was coming back, if she missed us, etc. Then, out of the blue he says "I am so disappointed in you, I am very, very disappointed in you. You forgot to take my mail down and therefore it didn't get taken to the mailbox and I had to run to the post office to make sure it went through."
By the way, he goes to the post office at least three times a day even when I am not covering which makes me think that his assistant forgets all the time. Anyway, I apologized to him and he said Well, you are going to have to do better than that, a lot better than that. He wrote me up for mispelling Michael on a phone note and says that I broke the computer in my office. I didn't as it was so old that the button just got stuck and wouldn't come out. It would have happened to anyone who was going to use that computer.
Any little thing he thinks he can get me on he will make a big deal of it. A lot of the times are when everyone in the office is gone so no one hears him. His assistant supports him 100%, although all of us employees feel she has her .....so far up his .....she is stuck there. His assistant was put in the basement when the last CEO was there as he didn't like her and she never followed through on her work, (she still doesn't). But, whenever she messes up it is okay. I had to correct the fact that she forgot to set up a meeting the CEO wanted. He came to my door and said, "Can you make sure that this certain meeting got done.?"
Now you know that his assistant, was very busy trying to get out of here and she had so much going on that she could have innocently forgotten. He was sticking up for her. His last CCO quit two months ago because he treated her like dirt and she had a three hour evaluation with nothing good to say about her at all. She is the one that got this organization through all the inspections, wrote policies and procedures, did all his work. She said something wrong one day and he had it out for her ever since then. If he wants rid of you he is on you like glue until you give up.
How can I stop the harrassing and let the board know what is actually going on? He is just covering himself with the board. They asked him why the CCO quit and he said Gee, I don't know. Don't ask me, I don't know. He golfs with most of the key staff and he has snowed them too. WHY DOESN'T ANYONE OPEN THEIR EYES AND SEE WHAT IS HAPPENING TO THIS PLACE? WHAT CAN I DO? I NEED SOME ADVICE AND HELP.
- Desperate
Dear Desperate ...
This is the most common question in Advice Line: I have an awful CEO; how do I fix the situation. The answer is, you can't. You can't effectively let the board know, because the board doesn't care. You can't have a heart-to-heart with the CEO because this sort of behavior works for the CEO. It's how he got to be CEO, in fact.
You have three choices. You can:
- Grow a thick skin so you don't care what the CEO says. Just nod and make appropriate noises until he goes away, then go back to your job.
- You can perfect the art of manipulating the guy. With an ego like you describe it shouldn't be very hard to figure out which buttons to push. His assistant has managed it, after all, and you didn't suggest there's a non-professional relationship there.
- You can leave. This is the best choice, because it gives you the opportunity to leave a poisonous environment and enter one where you enjoy showing up every day and are motivated to do great work.
No satisfaction there.
So give up any dreams you have of whistle-blowing. Give up any hope of turning the place around. Exchange it all for the hope of peace of mind - what you get from taking control of your career.
- Bob
Powered by ScribeFire.
Posted by Bob Lewis on August 8, 2007 06:35 AM
August 05, 2007 | Comments: (0)
Dear Bob ...
I'd like to submit a topic you may be able to shed some light on. I hope you can find a way to make this into something more generally useful to your readers.
There are a lot of traditional ways to do manage projects that may very well be good ideas in general, but if applied too religiously, you miss out on efficient implementations. The one I’d like to focus on, since I am a UI designer, is an old saw that you should “separate interface from data” and avoid writing code that ties the data to a specific presentation.
Perhaps that makes sense much of the time, but in the case of a very large project with lots of similar items, I disagree. For these large projects, I like to create interface engines that build the elements, their interfaces, and control the appearance of the presentation, all at the same time. This is almost the exact opposite of the old saw. In this situation, trying too hard to separate the data from the presentation misses the opportunity to design what I call a presentation interface engine.
The interface engine may very well take advantage of as many opportunities as is practical to separate the appearance from the data, such as properly applying very well-constructed CSS stylesheets to its elements. But rather than use lots of static pages and objects to define appearance, it uses code to build the interfaces into mostly blank containers.
The traditional data separation method breaks a large project up into a vast number of very-similar-but-different templates. They get hard to manage, especially when you need to make global changes.
Instead, the data presentation engine uses data to define interface behavior, such as validation, position, colors, and interface element types. The complexity goes into the database or into global application settings, where it is far easier to manage, and allows the graphic elements to be collected in a just few places where they are easier to change in a global way, but with plenty of atomic control because data is being used to control the specific appearance and behavior of each item.
Sometimes (but not always) it does take a little bit more time up front to build a good engine, but on a large project this leads to huge efficiencies, not the least of which being the ability to change the appearance or behavior of the application by changing data rather than code. It helps a lot that each new project has inherited some of the best objects from the previous app.
I do wish it was easier to get other people to understand how this saves time and make things less complex overall. I have decided that I just need to be patient and let results speak for themselves.
- UI Guy
Dear UI Guy ...
Thanks for the suggestion. I have to tell you though - this is far more technical than my standard fare, and I lack the credentials and expertise to weigh in on it.
I know this because in the late 1990s, in a project I was responsible for, I tried to take the UI design in this general direction. I wasn't able to make my case and the implementation team, of which I wasn't a part, did it the hard way.
Stated in less technical terms, what I think you're proposing is a rules-based UI engine which understands the data to be presented and displays it based on those rules. I don't think this violates the principle of separating data from presentation. I think it's simply using the word "data" twice in different ways. There's the data being managed by the information system, and there's the "data" - in the form of rules, parameter tables or what-have-you - that govern the appearance and behavior of the UI.
I see no problem there. It doesn't break the rules until you insert (for example) validation code into the UI application. Do that and you'll have to cut-and-paste the same validation code into every other UI program that shows the same data fields.
And that way lies COBOL.
In any event, I'm not sure I was qualified to weigh in on this topic back in the days when I was qualified to weigh in on it. I'm quite sure that among the subscribers to Advice Line are quite a few UI professionals who are in a position to make up for my limitations on the subject.
That's why this blog has comments. Anyone care to post one?
- Bob
Powered by ScribeFire.
Posted by Bob Lewis on August 5, 2007 03:05 PM
August 02, 2007 | Comments: (0)
Dear Bob ...
Normally I agree with you, but I guess this time, I am one of the prudes ("The new prudes," Keep the Joint Running," 7/9/2007), and am somewhat pleased with it.
Why? I work on a team of 6 people supporting server and desktop OSes, all applications that run on them as well as the imaging system. With all of the software we support, we had to come up with standard documentation that is MANDATORY for all installs, upgrades and changes. Before we had this we were always re-inventing the wheel and were never cross trained. Only by having our boss harshly enforce this documentation requirement, were we able to greatly IMPROVE our customer support.
Another place that I am pleased to be a prude is what software we allow on the users PCs. I have worked for companies that did not enforce this and were hit by software audits that all of the sudden became every expensive for the company as people were bringing in apps from home to improve their productivity.
Another example is that we have fought, and lost the battle to install the MS office suite on all PCs. Our management does not feel it can afford the cost. If all users were to install this because the felt they would be more productive, the financial costs to the company would be too high. While I wish I had the unlimited resources of a consultant, we cannot afford to give each user a copy of the software that they feel is best. When you count the soft dollar costs of packaging, installation, license management, updates, patches, security patches, the costs go up quickly!!! Standardization make this less expensive.
I can no longer keep track of how many PCs have had to be rebuilt because of some non-standard piece of software that the user brought to work and installed. My time would have been better spent on other things than rebuilding those PCs, even with all of the tools we have to automate the process.
The all or nothing approach as you presented does not work. What I mean is that my approach of being a prude all of the time, in every way I can does not work, just as the tone in the KJR of allowing a free for all in the name of efficiency does not work either. There is room for both approaches. Good managers (management) knows when to give, and when to hold the line.
Just my two cents,
- A new prude
Dear Prude ...
It's strange - whenever I write a column suggesting that end-users should be allowed to experiment and innovate, many readers interpret it as a recommendation for a free-for-all. That isn't the case. If you want a full account, take a look at "Revising the End-User Computing Manifesto, 10 years later," KJR 7/31/2006). It should clarify my position.
By the way: Having a standard procedure for establishing a standard build doesn't make you a prude. It makes you a professional. Likewise upgrades. It's when all changes have to funnel through IT that there's the potential for creating a bottleneck whose benefits don't warrant the costs.
The one statement in your letter I suspect might be exaggeration is the number of rebuilds resulting from non-standard software. My own experience has been that maybe 5% of all end-users would even be interested in installing anything. Doing the numbers, in a company with 1,000 employees that would mean 50 would be installing non-standard software. Since not every non-standard package causes a PC to blow up - far less than half, I'd say; most of these packages are professional-grade software whether or not IT happens to have approved them. 20% would be a heavy failure rate.
If I'm remotely close, this would mean a rebuild rate of about 10 PCs per thousand in a typical year. I rate that as an annoyance, nothing more.
My biggest issue with the environment you describe is this: Your company has decided not all employees need MS Office. I'm willing to bet this decision was made, not by each supervisor and team lead - the people who actually know what employees do and what tools would be valuable in accomplishing it - but by someone higher up in the hierarchy.
I'd say it's highly likely the decision-maker is focused solely on cost-avoidance, not on enabling value creation. Equally likely is that the decision-maker's name is now on the policy, which means changing anything in it requires the decision-maker to acknowledge that he/she didn't get things entirely right. Policy modifications are, in this situation, filtered through egos rather than business cases.
If you're one of the employees who officially doesn't "need" MS Office but whose supervisor gives an assignment that could be accomplished much more effectively with MS Office, what's the likely outcome? It's a classic example of IT saying, "We won't do it for you and we won't let you do it for yourself."
I presume, by the way, that you and your staff took a close look at OpenOffice to see if it could do what the company requires while being affordable enough to provide copies to all employees.
Arguing against a free-for-all is arguing against a straw man. You could make the same statement about my argument against total lockdown, except for one thing: Lots of IT managers really do advocate total lockdown, so I'm not arguing against a straw man.
- Bob
Powered by ScribeFire.
Posted by Bob Lewis on August 2, 2007 05:47 AM
August 01, 2007 | Comments: (0)
Dear Bob ...
One comment about your article ("The new prudes," Keep the Joint Running, 7/9/2007) that I shared with some folks on my forward list:
I lobbied for this position 3 years ago, and wanted to fill it (someone to build a rich end-user "tool kit"). "Not worthwhile," "not enough to keep someone busy," "no real need," were some the comments I got back. Sad thing is, I bet they still feel the same way today.
- Frustrated
Dear Frustrated ...
The sad thing is, your colleagues were right. There is no "need." It's a matter of asking the wrong question.
Those who ask what the business "needs" are applying Maslow's hierarchy of needs - an intensely human construction - to the corporation. If a corporation were nothing more than a big person this would be appropriate. But it isn't.
Asking what the corporation needs is the wrong question. Asking what provides sufficient value to warrant the required investment is the right question. When you point this out, those who disagree with you will hand-wave it off, explaining that it's "really the same thing."
It is, too, in the same sense that black is the same as white only darker.
- Bob
Powered by ScribeFire.
Posted by Bob Lewis on August 1, 2007 07:03 AM
|
Three books. Three ways to change the world, your life, or at least Bob Lewis' bank account. Leading IT: The Toughest Job in the World distills the world of IT leadership into eight learnable skills and gives you concrete, practical techniques for each one of them. Bare Bones Project Management: What you can't not do makes project management manageable, even for first-time project managers with no formal training in the discipline. ManagementSpeak: What managers say/What they mean … well, it won't help your career, and won't make you a better manager. Mostly, it will make you chuckle, guffaw, and maybe even chortle. Make friends - it's the perfect gift for anyone who has ever suffered through one of those meetings. Order your copies today! |
TOP STORIES
Sun exec on OpenSolaris, LinuxAT&T: No free iPhone Wi-Fi info
MS to appeal E.U. fine
XP SP3 causes endless reboots
Vista as insecure as Win 2000
Apple slammed on climate change
Java ubiquity an edge in RIA battle
Google grilled on human rights
MS' post-Yahoo options
The InfoWorld news quiz
ADDITIONAL RESOURCES

- Virtualization: A Step by Step Approach to Success
- Dialing up Agility with Business Transformation
- 5 Things You Need to Know About Storage Virtualization

- Virtual Test Lab Automation: Manage development infrastructure
- Improve Resource Utilization and Lower Operating Costs
- Protect Your Data with SSL


