The Most Essential Development Problem
Paul W. Homer has a post up discussing essential development problems. While this is a huge subject (somewhat reflected by the size Paul’s article,) I’d like to emphasize one of the things he touches: the lack of understanding the users’ problem domain.
The biggest problem in most systems today is the total failure of the programmers to have any empathy for their users.
I too have a similar perception, and I have many times been guilty as charged, although I’ve come to realize that I’d better take the Customer View if I want to succeed. Still, I fail from time to time in the analysis of the users’ situation. I don’t know why this keeps happening, but I think impatience and a strong wish to “get going” is partly to blame.
One part of the problem could also be how many of us look upon system development. We usually decide for technology at an early stage, often on grounds that matters little to the end users. Things like personal preference and hype usually have a big impact on the choices we make. We then build the system pretty much bottom-up, adapting the business process to fit the technology. I’ve seen this unspoken philosophy many times in many places, and the results are usually poor.
The cure is a change of paradigm. We need to start with the users, identify and help develop their processes before we build systems that support them. We need to realize that the system is not the solution; it’s just a part of it.
Another part of the problem is a question of attitude. We need to accept that we’re actually in the support business. Our job is to make things easier for others, not to take the easy way out on the users’ expense, as Paul also points out.
“Use this because I think it works, and I can do it”, produces an arrogant array of badly behaving, but pragmatically convenient code. That of course is backwards, if the code needs to be ‘hard’ to make the user experience ‘simple’ then that is the actual work that needs to be done. Making the code ‘simple’, and dismissing the complaints from the users, is a cop-out to put it mildly.
Of course, there is a trade-off between what users want and what we can provide, but at least we need to start at the right end.
Cheers!
I would agree with you in emphasising this particular problem in software development and I doubt that anyone would dispute that this is an old problem.
I think one of the big problems with information technology (and software development specifically) is that we enjoy junking all our learning every couple of years for the latest and greatest technology. We spectacularly fail to learn lessons from our past experiences, which is something we must counter as our profession matures.
Putting the user at the heart of the problem is central to the Structured Systems Analysis and Design Methodology (SSADM), which was developed in the United Kingdom during the 1980s and which became the UK Government standard. This methodology really belongs to the age of procedural programming and is probably a complete anathema to developers now versed in agile methods.
However, it would be a mistake to just dismiss it. Although its approach requires a strict waterfall from analysis through to design, it teaches many valuable lessons for the developer. It is stupid to look at the methodology and dismiss its techniques because they belong to the procedural era without asking what it was these gurus of the time were trying to instil.
One of the reasons we kept this methodology alive on an undergraduate programme I was partly responsible for until recently was it was a bit like teaching Newtonian mechanics in a post-Einstein age. Newtonian mechanics can be seen as a stepping stone to a more refined way of thinking about the World. It has many ideas and concepts which we should be careful not to throw away when moving forwards to new paradigms…
We felt it important that students had time to appreciate the important lessons this venerable methodology had to offer before advancing their thinking towards solving its inherent problems in an object-oriented world.
An example that touches on your article is that it locks the developer into concentrating on solving the business problem before addressing the technical aspects of the solution. It pushes the decision as to which technical platform to use to the last possible moment.
Perhaps we should look more for evolution rather than revolution as we move our thinking forwards in our profession?
I totally agree with your last sentence. And, I would love to see the rise of an agile methodology that focuses on business development as much as SSADM seems to do.
Your argument is attractive, but one must see it two ways: Just as we shouldn’t dictate or constrain the customer based on our technological whim, we can’t build them entire custom systems, either.
Each choice made delivering a system constrains both the problem domain and the range of available solutions. If the customer wants an internal tool, or a customer facing webapp, or a software widget that does ‘X’, it must be implemented on some extant hardware/OS/UI.
Then, as a practical matter, for any problem, there’s more than one way to solve it. Depending what sort of “shop” you’re in, or your individual aptitudes, you’ll chose the solution you like best. That solution might be EJB, or ASP.NET, right down through Rails, or an old fashioned native Win32 app. This is simple economy of scale–you must fit the customer’s problem to some similar problem you’ve solved before, or else you’re in a custom, one-off business.
One-off software is risky and error-prone, which benefits neither the customer nor the provider.
That being said…I think there’s a balance there and market forces should find it. A provider or employee should be accountable to his customer that he’s using the appropriate technology to solve the problem the best way. If he won’t commit to doing that, the customer shouldn’t have hired him in the first place.
Good points, and I agree with you. We have to reuse technology, and take into account the cost of using (to us) unknown technology. All I’m saying is that we should thoroughly look at the business process first. My experience is that when the technology choice is taken, we usually have a poor understanding of the users’ problem.
Sure, but the basic problem is that users don’t understand they work in an IT world.
This is what happens on every successful project I’ve been on:
1) users/customers produce a list of features they’d like. All of them are rated must-have, none of them show any awareness of scope containment or budgeting. Often they include things that would require Microsoft to stop changing its file formats between office releases, or release detailed internals of windows. Or assume 100 programmers and five years development time. Did I mention the budget is $25,000?
2) the business analyst, either a new hire or a programmer determined to be totally incompetent, types up the list, and passes it to the developers and architects
3) the developers and architects do the job of balancing, prioritization, actual requirements, translation, design, scoping, scaling, business analysis, ROI, and everything else. Remember, this is for successful projects. Unsuccessful projects have bad developers, and you get bupkus out of this process.
After five decades of enterprise computing, almost every user and manager behave like they don’t understand what it takes to implement an IT system. Many of these workers are 30 and 40 year olds that have been in the business ranks for 10-20 years. And they blink dumbfounded when you explain what the QA process is, what requirements are, or that you can’t deliver the system one week after the users spent a year scratching their nuts over requirements.
Well, I can’t argue with you. The picture you paint conforms to my experience as well. It seems like – in order to be successful – we have to do all the work ourselves. What difference us is how we choose to face that fact.
We could either:
– complain about poor requirements, make the best you can out of them, blame the customer for the poor results, or
– work with the customer throughout the entire project, helping them all the way, through business analysis, with requirements, prioritizing, testing, launching, the works.
I personally find the latter being more rewarding, and effective.