I'm Sick of Developing Dumb Systems

[PTCruiserII]

The intelligence of business software I develop has gone down hill. I spend 95% of my time worrying about interface.

The smartest programs I wrote were in the DOS days when interface was secondary to getting a job done. This would mean automating processes to the fullest possible extent with the technology of the time.

Today the mantra is 'GIVE THE USER WHAT HE/SHE WANTS'. This forces dumb software with nice interface to be the norm.

An analogy I use is:
If we're in the business of digging ditches, if I asked the ditch diggers what they needed to do their job better - they would never conceive of a BULLDOZER. Users can't conceive of a world where they don't exist. They would much rather have a mechanized shovel - it would be easier for them but wouldn't be using technology to its potential. The shovels would look nicer, and they would all be linked together and require upgrading periodically... --- you see where I'm going.

Just thought I would vent a little...

 

[JimHorton]

Pt,
I'm with ya...everyone wants bells and whistles. My apps look spartan but they're efficient, logically sound, and they don't crash--an ethic I picked up before things got crazy.
--Jim

 

[BeckahC]

Yes!!! Just as I get things working as they need to be, to be the most efficient they can be on my application.... One of the users asks for the most stupidest change to the interface - can you make the font bigger? Can you add in an extra field (on the screen) so we can keep track of this in this screen, without going through steps A,B,and C - like the boss requires? (I wish I had an eyeroll pic right here!) Like One user asks for something to be changed... I go through filling out the forms management requires for changes to be made... then I make the change and someone else doesn't like it, but has a better idea.... None of these ideas or changes change how well the program works... it just makes the interface easier on one user's eyes, harder on another... then the next change reverses that - I would love to get back to actually programming instead of tweaking the Visual parts of my programs!

(Thanks! I really needed that! ) BeckahC

 

[Guest_imported]

We were a Foxpro-centric data shop. Our fulfillment system is so bloated that we upgraded our network infrastructure to deal with the access problems of a file-based data store. The IT manager hired to fix the problem is decidedly VB/msSQL-centric. We have editors using MACs too, so they aren't able to run the executables IT had been using. Our low-end desktops are underpowered for most DLL-heavy applications. We also had very poor interfaces because the development time was always next to nothing, so the interface usually was left to bare minimums.
Our solution has evolved into a web-based interface written in a general enough way that new 'applications' can be deployed in the standard interface simply by adding a few records to the SQL tables that control the menu system and the action. Macs, low-end PCS, remote users, etc. can all use our intranet. The developer spends time working on the data process, and the interface is standard and simple. Frankly, i'm amazed at how easy it was to design and implement. We started with the idea that no one would become the indespensible owner of any query (so any competant IT hiring would be able to inheret your position) and that the core of this application would be intact at least 10 years from now. (Since we never can't justify upgrading a system that does it's job, it should be designed with longevity from the start- ie: no "Y2K" type obsolesence)

I'd like to be a developer and then hand the support of what i've created off to a lower-level tech support person. My time is lost repeatedly going BACK to untrained users asking the same set of questions (and maybe a bit of stuff we didn't conceive during initial project specs)

 

[BeckahC]

speaking ass the only person who is completely versed in my main program - start to finish, how everything works, etc... I'm surprised they didn't call me last year on my honeymoon to ask me things! ;-) BeckahC

 

[BeckahC]

let me apologize for my typo! :-0 It's been a long day and isn't even 3pm yet... BeckahC

 

[MasterRacker]

I would suggest you red-flag your own post and ask that an 's' be edited out, but it more amusing as is... ;-)
Jeff
I haven't lost my mind - I know it's backed up on tape somewhere ....

 

[BeckahC]

Oh my.... thank goodness for spell check and syntax checking... my program I was working on yesterday might have blown-up! ;-) BeckahC

 

[PTCruiserII]

My original point was this - if programmers can automate the flying of a commercial jet airliner - why are we forced to produce such stupid business software that our users still have to enter address fields (every address is on a DB somewhere) or enter dates or make scheduling decisions.

An interface should show graphically if everything is going OK - just like your car does - most cars have warning lights, not gauges, because most of us don't know the correct operating temperature of our engine oil (for example). Instead, we are perfectly willing to let the car do all the work - we just steer it.

So the perfect interface in my opinion, is the dash board - this is visual but with little required user input. But it also requires that we build software that acts as a modern car. A user needs to steer that application and apply actions that give instant feedback. Maybe even pressure and sound effects when your decision may cause a negative effect (on your budget for example). In fact budgeting software would be an excellent candidate for a dashboard interface. Budget = Gas. Rate of burning cash = speed. Brakes to slow down. Time to destination. Now in an organization, you would have many cars (budgets).....

 

[BeckahC]

Sorry to have gotten off track -

I think it would be great if we could get that automated - but as you and others have said... people are afraid of losing their jobs to progress... with the rise of the computers came the downfall of many factory workers... How many assistants (secretarial/administrative) would or will be put out of work by PDA's and other such marvels of technology... of course, being a programmer, my position is relatively safe, as long as I can come up with new ideas for programs and systems that are useful, so am I... but not everyone can say that, or think that. Progress is slowed by not only the people afraid of change, but by the people afraid to be useless....

Just a thought - I am, as I said, all for further automating "life" and making things easier... I just like to slip into other people's shoes once in awhile - like when I have to think of how my users will be affected by any of my changes to my programs... (I guess I'm just a sensitive programmer at heart ;-)) BeckahC

 

[PTCruiserII]

Hi BeckahC!

Once upon a time we had blacksmiths who were extremely in demand and had a crucial - highly skilled job. Along came the car and according to you they were out of work - but in fact they were put to work building cars. Now, robots can build much of most modern cars. Will these people be put out of work? NO! They will be employed building ROBOTS. Similarily, business software can (if allowed) displace office workers - who will be employed developing or maintaining more and more sophisticated technology. Be optimitic about the future and embrace automation. Your users will be happier in the end.... Automation that enforces the status quo is not progress.

 

[BeckahC]

I wasn't actually trying to relay my feelings... but the feelings I seem to get from my users whenever I introduce something new... In trying to understand their way of thinking, I try to come up with better ways of introducing the changes to show then that it is to their benefit, rather than my justsaying that and they just think that that's all I'm doing... just saying that. The analogies you've used are excellent... I hope you don't mind if I use a couple as examples for a few of my more stubborn users?

(I still have a couple of user who think it was easier when they just kept track of everything in their heads and let us know what was going on when they felt like it... X-)) BeckahC

 

[PTCruiserII]

Hey BeckahC!

I've got alot of analogies for you - like the one about the baker and the bakery(production line versus custom made output)...or maybe the backyard / lawnmower(db versus word processors)...also the car door (user request analysis related to car door). My best tool for user requests is the zero time rule (if you had everything you ever wanted instantaneaously - then what would be your next request!!! This one gets people where it hurts because than they have to start thinking about just what they do instead of just focusing on information availability and speed).

 

[BeckahC]

Thanks PTCruiser!
My company seems to be of the mind that the higher-ups discuss something, make up their minds, then the people (programmers, tech support, engineers, etc.) are just expected to tell them how long, what's the cost, etc. There doesn't seem to be a great deal of concern for the user that calls me up first thing in the morning after a change was implemented and asks why we had to change the system that was working fine... I'd like to be able to tell them more than just "because we upgraded" I try to tell them "we made system improvements, once you get into using it this way, you should see just how much better the system has gotten" of course, when they call me again later, to complain again, it's still me that has to come up with that bridge that brings them over to the newer, better version. I think some of your analogies might help me explain that the change is for the better a bit easier

Thanks again! BeckahC

 

[dilettante]

A lot here that's thought provoking.

Personally I have screwed myself time and time again by giving over-optimistic time estimates.

I'm thinking 'bout a new formula:

T = 2 * (Guess_best + Guess_{user interface})

Where T is my time estimate. What I am saying is to first make an honest "best guess" at what I need to do the job, secondly to add in (again) the part of my guess I think will be spent on "user interface" issues, and finally to double the whole thing.

It seems like everything always takes me twice what I think it will, and user interface issues are about 4 times my best guess.


Regarding the comments above re. form vs. function...

I spent many, many hours building a really useful and sophisticated Windows desktop application. It hasn't sold worth a crap.

My brother asked me to write a bulk file-renamer (you know, just rename all the files in a folder as F001.jpg, F002.jpg, etc. where the user can pick "F&quot. He specified that it be super-stupid to use, and as colorful as possible without being actively garish.

I whacked this out along with a small Help file in VB in like 10 hours including debugging, two passes at approval and tweaking of the user interface, creating related graphics, icons, etc.

He sold this thing for like $6 on a CD, paying me $0.50/copy royalties. I figured, "yeah who'd be dumb enough to buy THAT?"

He's already sold about 200 copies in two weeks.

Who is the dumb one now?

 

[BeckahC]

That's terrific dilettante! I, too have problems estimating a time frame for my projects... I told them this one I'm working on now would be done by the end of Jan. Of course, with the additions that have been made over the last few months, and a few unpredictable delays - hardware ordered that did not come in on time... others involved in the project not in on particular days, or not letting me know when they'd be on vacation, etc... but as the project manager, I still get the responsibility of coming in as close to scedule as possible. My currect guestimate of project completion = beginning of April....X-) That equation of yours sounds about right! ;-) BeckahC

 

[MasterRacker]

The formula I learned back when I was a programmer for estimating is to make your most honest, best estimate then add one and change to the next higher unit. Example: if you think a job will take 3 days, schedule it for 4 weeks. ;-)
Jeff
I haven't lost my mind - I know it's backed up on tape somewhere ....

 

[BeckahC]

Jeff, that's great!!! LOL I'd be way on time now if I did that - of course, I don't think thay'd believe this would take 3 quarters (or 3 years!) Not to mention, this was the first project I've done that had the "new way" of paperwork (that would be almost more time on the paperwork and ocumentation than on the project itself ;-)) BeckahC
X-)

 

[jasek78]

To deal with UI issues at the place I work at, we give the customer an estimate (after adding in an extra week or so worth of hours), and then when they want additional changes above and beyond, or if the customer is late in signing off on a project, we just revise the estimation to compensate for the lost time. The most important thing that we do now to deal with it is to keep good contact with the customer (which is difficult to do, at best) and when they come to us with changes, to remind them where they are in terms of hours estimated vs. current worked.

jason

 

[PTCruiserII]

With regards to estimating - I feel it is the project managers / programmers own fault that project estimates are ALWAYS short. The reason is clear - we LIE.

Let me explain - we love new projects - it is what we live for - nothing is worse that being stuck in a stale project or in maintenance.

So when the oportunity arrises for something new - when we are asked for an estimate - we already have a good idea what the sponsor/customer is expecting us to say. There is always a level of subconsious feedback that we hunt for when dealing with someone who is paying us to develop systems. We would be stupid if we didn't. The problem is that the user request doesn't match with the user perception of when they need it. In fact these parameters are usually inversely proportional.

My usual way of handling a request is to go for established programming tools at the time. Second anticipate hardware / network speed will double by the time the project has completed (even if it is under a year). With these two assumptions, you will be using tried and true development environments but you won't be overly worried about performance.

Also - remember the well known saying - Walking on water and developing computer systems from user specs are easy when both are frozen...