2 ms·

The most interesting and difficult part about business programming is that your clients rarely have a good idea what they want. They say they want searching, b

The most interesting and difficult part about business programming is that your clients rarely have a good idea what they want. They say they want searching, but what searches will they commonly want to perform? What type of data are they looking for on a daily basis and is there some kind of daily report they didn't think of which would be useful to them? They claim that such and such will never ever change ever, but what happens when it does, and how can our system adapt to that? Taking a VERY vague description for a database frontend and fleshing it out into a useful, intuitive, fast website actually IS fun and interesting and non-sucky to me. Seeing a client visibly pleased and impressed with my work is very fulfilling and rewarding. Experimenting with new technologies (in moderation) to accomplish these tasks is fascinating and educational.

edw519 18y ago
...your clients rarely have a good idea what they want... Not my experience. Once you frame the question properly, they often know exactly what they want. It's not that they need "search", it's why they need search. "Oh, you need to be able to determine the top 3 x's whenever y happens so that you can do z." Fine. Just tell me the "what" and the "why" and I'll figure out the "how". I understand your pain. Most of my clients skip ahead to the "how" before expressing their implicit "whys" and "whats". It's our job as systems analysts to slow them down and do it right. But then we never did sign up for easy, did we?
- EliAndrewC 18y ago
  That's definitely a good distinction; that clients CAN tell you what they need by if you ask the right questions. Of course, one major constraint in large corporate/government development is not being able to speak directly to the people who will actually be using a system. I've often had the experience of spending months developing and producing a working system before being allowed to show it to any of the eventual users. While incredibly stupid and occasionally frustrating, this can make development much more interesting and challenging.

edw519 18y ago

...your clients rarely have a good idea what they want... Not my experience. Once you frame the question properly, they often know exactly what they want. It's not that they need "search", it's why they need search. "Oh, you need to be able to determine the top 3 x's whenever y happens so that you can do z." Fine. Just tell me the "what" and the "why" and I'll figure out the "how". I understand your pain. Most of my clients skip ahead to the "how" before expressing their implicit "whys" and "whats". It's our job as systems analysts to slow them down and do it right. But then we never did sign up for easy, did we?

EliAndrewC 18y ago
That's definitely a good distinction; that clients CAN tell you what they need by if you ask the right questions. Of course, one major constraint in large corporate/government development is not being able to speak directly to the people who will actually be using a system. I've often had the experience of spending months developing and producing a working system before being allowed to show it to any of the eventual users. While incredibly stupid and occasionally frustrating, this can make development much more interesting and challenging.