- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
This is very very true. When I came to the USA many years ago, I was shocked at how companies here viewed IT. In the Far East, in-house IT depts are viewed as one of the keys to competitiveness, lower costs and higher productivity.
Steve would have his own little team of dba's, developers and testers. Steve interacts with the business, evangelizes solutions and translates them into technical requirements. The techies deliver and everyone - everyone in the company - benefits.
Here, more often than not, IT is just a "cost" on the balance sheet, filled with people who are not connected to the rest of the business, and managers just waiting to get slammed when the next outage happens.
Admin
Holy cow. We have a Steve-in-training at our office.
We just cut over to a new web application that allows our three offices to input and track data from 200 or so users for 9000 customers, with lots of specialized, complex business logic. As expected, there were a few hiccups and we spent the week running around, identifying bugs, and gently squashing them.
Our "Steve," always happy to take an interest in what's going on in IT, wanders over and strikes up a convo with one of the programmers (okay, I'll admit, it was me). He started by asking what kind of HTML editor we were using.
Rather than trying to explain the subtleties of an MVC architecture smeared across six servers to an obvious dabbler, I just told him that our HTML was hand-coded (which is mostly true, thanks vim!) The phone rings, saving me from more face time with Steve.
Next thing I know there's an e-mail sent to all them managers in the company, stating that the problems with the new application are because... we didn't use Dreamweaver. According to our self-elected technical analyst, "Dreamweaver can do the work of at least 6-10 people doing hand-coding." After establishing his technical authority by stating he "took web design in college, in Ohio" and soberly warning that "We want to be the top over our competitors" he launches into a lengthy spiel on Dreamweaver's featureset. With interjections like "Writing
code by hand, is like the dinosaur method" and "Looking for web problems in
code, is like looking for a needle in a haystack" one wonders how our development team, with a combined 30+ years experience, could have missed this simple solution to all our problems.
He wraps up with the following: "All the best web designers, I 100%
guarantee, use Macromedia Dreamweaver MX, Flash, Fireworks, Freehand, and MS
Access. And a lot are using Swift for 3-D animation. " Which has exactly zero to do with a business application.
I know this is not really the place for it, but after sinking six months of work into converting the messiest mishmash of half-assed databases, excel spreadsheets, and faxed paper documents I have ever seen into a single, usable framework, I really don't know whether to laugh or cry about this (I've settled, so far, on a kind of half-choking hiccup, with ryhtmic hand-clenching).
Only another programmer (or my wife) could understand.
Admin
It's nice you take the time to respond, inserting a carefully constructed answer to my comments, paragraph by paragraph.
Except, of course, the ones you don't like. They're the interesting ones.
Like: do you actually understand what Excel can do, so does your solution act in a similar fashion, being real time, with user configurable results. That is, they may want to check on green bras sales for all region on Monday, but narrow it down to just red A-cups in the North & West regions on Tuesday. Keyword: Dynamic.
The other (also asked by others), being: will your solution actually be any better than Excel? If so, why?
I have no idea what this means: "This flexibility is usefull for adhoc queries and rapid prototyping, but I wouldn't want it to directly access productive databases. Just because of that."
What difference does it make if it's Excel, C++ or a Java app hitting the database?
I'm not expecting an answer, beyond 'we follow industry standards by using Java blah blah blah', which isn't really an answer.
You're a little bit older than what I expected, so you either started late or you're a bit of a slow learner. If you said your first computer was a Timex or Apple II I wouldn't be surprised. I'm a little older than you, not that it matters much.
Tell you what, you obviously don't have a clue regarding Excel, how about I whip up a 'Steve Special', nothing fancy (pull data off web & graph), send it to you, and let's all see how much better you could do it. Feel free to suggest the dataset & results.
My current job is writing a quotation calculator, only about 75 users, I think. (2 months / $45k, AU$ so don't get too excited). I've done a few others, this one is a bit more complex. Excel turned out to be the only real contender (I suggested others, and was told, 'thought of that, can't use it because of...') for various reasons, like 'no install' & 'works offline'. Pilot is up & running after one month, app will be completed in another. Has an Access backend, will move that to SQL-Server & ASP if the pilot succeeds. Got a standing ovation at the demo, that was a shock. 3 bugs to date, one typo (dang), one bad data (not me), and one bad calc (yep, mine). Five years ago I'd have fired up C++, and been due for a pilot in 2 more months. Maybe.
The name of the game has been RAD for a long time, and Excel is very RAD. I'm taking 2 months off after this.
Anyhoo, I've see you brought up the 'but what if it lives forever' argument. Well, what if it does? Doing it right is nice, but most software dies quickly, either the technology changes (say DOS > Win) or the problem changes. Often that happens before the app is even finished. The argument tends to fall apart when you realise that if you have an old app, you maintain it with old tools (even on old hardware). In effect, time stands still for that app, technology wise.
Having the problem change will break anything, done right or not.
I've plenty of 'right' stuff gathering dust. DOS stuff. Windows COM controls. Powerbuilder apps. dBase files. Paradox files. C libraries. PCX graphics. All junk. All that time, and nothing to show for it. What a waste. The only people I can show it to who might be impressed are other programmers, whoopee.
A system I worked on a few years back was so old it pre-dated DOS, the running joke was it pre-dated computers. It would be about 27 years old now, and is still used by thousands of users. Y2K would have broken it, so the effort was made to clean it up, to 'do it right'. At least six months later, all 'do it right' managed was to add more bugs. Noble effort, but Jan 1 was looming.
I eventually fixed it with a one line change, and ditched at least 6 months of work in the process. Smart project manager.
Packed Record
Day 0..31
Month 0..12
Year 0..99
End
I've forgotten how Pascal does structures (Integer in there somewhere), the above is close enough. I like the idea of setting the limits, more high level languages should do that. Packed means internally Pascal will use a few bytes as possible, on most languages the smallest you will get is 3 bytes. Pascal does it in 2. Day only needs 5 bits, Month 4, and Year 7. 16 bits. 2 bytes. Neat, if you're the bit-twiddling type.
So I changed the 99 to 127 (still 7 bits), and everything was happy. 2027 will get exciting for them. I worked there for a year, and basically that's all I did. (I'll agree that it's an extreme example.)
About that time I realised 'right' was bollocks for the most part. By the time you get your big framework up & running, the world has moved on.
Same company had a programmer working on a label designer for another app. He'd been at it at least 3 months. The users could design their own labels for putting on bottles. Like most programmers, the real world was a foreign concept. In the real world, users don't do labels. Furthermore, once a user had a label design done, it never changed. Besides, they always used one of the pre-set ones anyway. So rather than accept that the user will just ring up and ask for a new layout, which takes only a few minutes to do internally (help desk), this guy was 'doing it right'. And probably still is.
Strange I didn't accept the offer of a permanent job there... Must have been the 4-inch thick spec...
Tony
Admin
He wraps up with the following: "All the best web designers, I 100%
guarantee, use Macromedia Dreamweaver MX, Flash, Fireworks, Freehand, and MS
Access. And a lot are using Swift for 3-D animation. " Which has exactly zero to do with a business application.
Right, so you gain a few boxes you can sell on eBay. Sounds good to me.
Don't forget to update the generator metatag in case someone checks it.
I wonder how Access ended up on the list.
Tony
Admin
If this is what users need, they will get it. Of course, when more and more flexibility is added, at some point it becomes pointless to do it in a custom program, since the program will be like an Excel clone.
(This is where programs like Oracle discoverer shine...)
Let's assume my solution is a webservice, available in the intranet and extranet. (I say "assume" since a serious project starts with requirement analysis; the choice of the technology used to build the solution is based on this analysis)
This solution is available to everyone in the company who needs it, whenever he needs it. Like all webapps, it's also available when they are not on their own PC. Since it is server-based, it can use connection pooling to reduce the load on the database. Some databases, for example Oracle, take some time (say 1.5 secs) for the sign-on. I don't like the idea of 100 users, all running their Excel apps that connect to Oracle, make one query and disconnect in minutes interval. Since it is a web app, it's also easy to cache the results. If I find out that 25 people run the same query every minute, I let a process generate a static HTML page every minute and those 25 people get this static HTML page instead of a direct query to the database.
Since the IT department makes the reports instead of the renegade hacker, other advantages arise. The IT people could e.g. identify that many reports join the same combination of 3 tables, so they build a view for that query. If this query is rather expensive, and they use Oracle, they can make it a materialized view to speed it up.
Real time: If this is a requirement, an application can be made to fullfill it. If realtime means "fractions of seconds", it probably won't be a webservice, though. (back to "requirement analysis")
And, as I have already said at least 3 times, in some cases Excel might be the right tool.
In a three-tier architecture, nothing outside the server room ever "sees" the database. Everything that runs on the client's PC acceses a service on the middle layer.
Even in the traditional Client/Server architecture, where a "fat client" (let's say it's a VB program) directly accesses the database, some testing is done before the program first goes to the production database. You wouldn't let your junior programmers work on the production database, would you?
Even if you Excel app only queries data, it might accidentaly access a database view that is very expensive to get. In a database where reading blocks writing (not Oracle), the innocent Excel query might cause problems for other processes. The VB program could cause the same problems, but that's what the development methods are for.
Blindly following the "industry standard" buzzwords is just another (more expensive, though) way to hell.
My first computer was a Sinclair ZX81, I think it was sold as "Timex Sinclair" in your country. And no, I'm not a slow learner.
Pointless. Some of the tools/libs (like the servlet mentioned) I use for web apps are not free, so I could only return a nicely formated HTML page to you. I doubt that would satisfy you. Or I mock up the most simple JSP page I can make in an hour or so, but how could it be better than the Excel app in isolation?
What you do seems like a serious project and not like a 15min fire-and-forget hack. If Excel is the right tool to make that, it's fine for me.
There are some strategies to mitigate this problem (3-tier and stuff), but the "lives longer" problem has to be viewed from the other side. Steve makes an Excel apps and forgets about it. Some months later, the environment changes, but the Excel app is still in use. Shortcomings of this quick hack slowly become serious problem, maybe unnoticed for some time. For example, let's say the app is undocumented and unregistered (nobody but the user knows about it) and the database is modified. Suddenly the hack shows wrong results, because the meaning of the 7th column of that table has changed, but this is unnoticed until real bad decisions are made on that data. (This is obviously a problem of every quick hack and not in any way specific to Excel)
The better the system is made, the easier changes are made. Orthogonality is the keyword. But there is obviously a point where it's cheaper to make a new system.
I don't think an application is "right" or "wrong" because it uses technology X or Y. Granted, some technologies like "Cobol" more likely make it "wrong".
It's right when it fullfills the requirements and meets the quality standards.
Clever people have invented processes that hopefully lead to "right" software.
Using the big buzzword-compliant framework of the week is IMO not the same as "doing it right". It's just an easy excuse for not doing the real sophisticated work - analysing the problem and choosing the most appropriate way to solve it.
The real WTF is that the programmer is re-inventing the wheel. Google finds 1.4e7 hits for "label designer".
Admin
I want to add a more generalized statement why I don't like renegade hacks, Excel or VBA or whatever.
There are three premises:
a) The IT department should know the users (business') needs.
b) The IT department should know what how the IT equipment is used.
c) It's the primary task of the IT department to deliver the necessary systems so b) reflects a).
Renegade hacks make it unlikely that this ever takes place. Instead,
a') Users ask Steve for help.
b') Steve's apps do unexpected things with the IT equiment.
c') Since Steve makes the apps, the IT department forgets its primary task and becomes the janitor of the server room.
Admin
I guess it's easier to criticize something you haven't seen than it is to try it out and see for yourself.
Get it here and then decide:
http://turboexcel.com/freetrialnew2.htm
Admin
In the context of translating a working Excel spreasheet that Steve created to a working C++ program that can be supported by IT, it's a true statement.
For brand-new projects, it's not quite as true. But the time spent debugging and testing the spreadsheet is still dramatically less than doing it in a higher level language.
Admin
The title of the thread makes it seem as if it is about Excel, but the text of the post is really about Steve, the IT department, and the business users.
Excel is like any other enabing technology: any language, any tool, any OS, computers, the Internet, the printing press, guns, nuclear power, whatever. It helps lot of people, and it hurts lots of people. Sometimes people are hurt intentionally, and sometimes unintentially. But it's important to recognize that we can never go back, except via extinction, which looks increasingly inevitable.
Perhaps someday a tool will come along that will be very easy and very useful that will cause lots of end-users to solve their problems and Excel developers will get on a board an bemoan how dangerous it is.
Admin
It can also happen where IT is incompetent yet holds the keys to everything but macro programming.
Admin
WTF? If you aren't thinking scalability with your code, then you need a better design style.
But I respect and agree with everything else you said.
Admin
The real WTF is that IT isn't in touch with the users. That's all.
If the IT dep had been on the ball, they would have heard about that cool new spreadsheet. And hearing about it and how cool it was, they would have had a look at it and either fixed it or developed a better solution.
And if they had been really on the ball, users would have gone to them in the first place instead of asking Steve.
It's not like it was implemented within a couple days. By the time the problem occurred, the app had spread by word of mouth and Steve was gone. So there was plenty of time for a good IT department to hear about it... if it was actually in touch with the users.