Slashdot Mirror
Software Development's Evolution towards Product Design
An anonymous reader writes: "The Lost Garden site has an excellent post on software development's evolution into product design. He starts with the first attempts at software design (for yourself or a colleague), and brings the conversation forward to modern design settings." From the article: "At the dawn of software history, programmers wrote software for other programmers. This was a golden era. Life was so simple. The programmers understood their own technical needs quite intimately and were able to produce software that served those needs. The act of software development was a closed circuit. A programmer could sit in a corner and write code that he wanted. By default it also happened to apply to other programmers."
Randomly throwing elements into software from the ground up rarely works well; everyone knows that early design is important for the software to be easy to use. In fact, intelligent design saves people from thinking about the software creation process at all, since the intelligent designer keeps the underlying processes of the software hidden from the user. Put your faith in a good intelligent designer and you can simply use the software and remain blissfully ignorant of how the software actually works.
I Am My Own Worst Enemy
Momma told me software was created by Flying Spaghetti Monster...
If you disagree with me on social issues, then it's pretty clear that you are a narrow-minded bigot.
Understanding the actual needs of the enduser, I think, is one of the biggest challenges for programmers. What do they really need? Will they understand it? Will new "gee-whiz" features really be welcomed? And for that matter, do the programmers really undersand my job?
To sum up, it's easier to program for yourself than for others, it seems. You know your job better than anyone else. Otherwise, you have to do a lot of interviewing and discussing before you code a single line. You'll end up with a *much* better product if you listen to your endusers well.
Anonymous Cowards are at -6...
This is why I think certain elements of extreme programming should become prominent in the software industry, particularly user stories and incremental releases.
The non-technical customer can provide the programming team with "stories" about how they would like their software to function, and rate these stories based on priority. It is up to the programming team to figure out how to do the technical work in the software to accomplish make the story (or use case) a functional part of the software.
Then, the team can incrementally add these user stories and show the customer a working prototype, so that if the design isn't exactly what they expect, it is easier to change and hopefully to maintain.
I got nothin'
"At the dawn of software history, programmers wrote software for other programmers."
I thought the first programmers wrote software to figure out ballistic missle trajectories, crack ciphers, count census figures and perform other useful work. What exactly is our clueless author whining about?
People often treat code like a paper. You want something added, you type it in and flesh out the paper. I think that this is why software often ends up working so badly. If people would treat their programs more like engineered pieces of hardware than written works in progress, things would be better. It just seems to me that people all too often forget that software development requires real planning and that it's not as simple as "I want feature X" in many cases. Maybe the solution is extreme extensibility. Cars can be modded in pretty complex ways. Perhaps the solution for software development is building a consistent core that just works and then plugging new modules into it, sort of like Eclipse.
As much as I wanted to finish reading the article, I just couldn't get past that. It is well documented that 83.8% of Slashdotters who share my interests and read the RTFA reacted the same way.
Cute illustrations, impressive list of references... but I haven't been able to extract any useful information from the article. Yes, writing software that people want to use is hard. Yes, listening to customers is very important, but also a lot trickier than "listen to your customers". Yes, to write successful software you need a mix of many different skills, not just programming, and yes, it is often difficult to even know what those skills are, let alone to find people who have them and to get them to work together productively.
Is any of this theory really that groundbreaking? I like to think that all these concepts are self-obvious to anyone involved in the software industry - the difficult part is actually translating them into reality.
ClutterMe.com - easiest site creation on the Net. Just click and type.
I'm a developer on a product team at a huge software company. I've worked on 6 shipped releases of the same product, and I've worked within the same core feature areas for about 3 of those releases. More than half my time each release cycle is spent helping the feature team to identify user scenarios and optimize ways to solve them.
One of these core feature areas had frustratingly low usage and user-satisfaction ratings for years, until we got serious about feeling users' pain. It took lots of usability testing, using the right tests and asking the right questions, to finally expose a number of thematic problems users were having. It took even more usability testing on many iterations of designs to find approaches that really solved those problems well for most users.
The most educational lesson in all of this was that the things the product team suspected were user pain points were often not so, and the things the product team thought were fine were often problematic. In other words, the product team's very educated guesses were frequently wrong. These were people who had worked on the same product, on the same feature areas, for years, often looking into bugs and suggestions sent in by real end-users. If anyone was qualified to make an educated guess, it was these people, and yet they were often wrong.
We didn't make huge technical changes under the hood or introduce loads of new power-user functionality. We didn't just try to pile hacky bug fixes on top of the existing user experience. We didn't just try to optimize the performance or speed of the existing feature. We listened to what real users were telling us, and we squarely addressed their frustrations and confusions.
In the latest round of usability testing, the feature scored more than double the old user-satisfaction numbers, and there will be even more improvements made to address more user feedback gathered from that testing. We anticipate that when the next release ships, this feature area will have dramatically improved user-satisfaction and significantly reduced abandonment.
Now, I think about my Kubuntu installation on my PC at home, and about the variety of open-source applications that I use on it, and I skeptically wonder: is the same kind of feedback loop and concern for non-technical users applied in the open-source world? It seems like most developers of open-source software spend more time developing what they think is cool, or what other geeks might want, than trying to identify and eliminate the pain experienced by non-technical users. Even when some open-source projects (say, GNOME, KDE, or Firefox) are genuinely trying to make things easier for non-technical folk, they are often just flying blind, copying the UI of commercial software or taking wild personal guesses at what they think non-technical users want. Their guesses, although well-intentioned, are often completely wrong.
The moral of my story: you have to approach identifying user needs in a scientific way, or you'll almost never get it right. You have to perform your own research and perform it frequently as the design evolves/iterates. And no matter how crazy the results of that research seem to you, the software designer/developer, you should still trust in them.
Moderator hint: a comment is neither "Flamebait" nor "Troll" if it is true.
Hrmph...
Seems to be yet another self-agrandizing Product Designer/Manager whose thinks that they "understand" the software development process. What's crazy about this article is that I haven't worked in a company that *doesn't* work like this. And yes, we have generally produced large quantities of user-useless poo.
The problem is largely due to the attitude of these guys. It's just another "throw it over the wall" to the programmers illusion. "If we just work out all the details before we write any code, we'll get it right the first time!"
The difference between most consumer goods and most computer software, is that computer software is a great deal more interactive than other things. It's therefore orders of magnitude more difficult to understand the subtleties of human interaction problems.
Usually, what I find is that these "product designers" have only a vaugue understanding of what they want, because they are not techinical (well, pedantic is a better word) enough to understand the difference. They figure out 10% of the problem and "throw it over the wall" to the programmers, saying "implement this, and I don't want any backtalk, you unwashed heathens".
So the programmers do what they do best -- solve problems. Only since they've never even seen a customer let alone talked to one, they get it all bass ackwards. The product "designers" then say, "Oh, well I told him what I wanted, but he insisted on doing his own thing -- it's not my fault".
Production pipeline indeed. It's some kind of pipe, but I'm not going to smoke it.
One of the first things my "guru" told me. Your user is the one who will use your tool. It can be the best tool ever, if its interface sucks, nobody will use it.
Now, I don't enjoy UI design. I hate GUI design. I HATE flashy button design. But that's what makes your user happy. And I am happy when my programs are being used. Does it make sense that my new interface requires DirectX 9.0 (for a "normal" office application, mind you)? No. But it looks good, gives the user a fuzzy nice feel and he's feeling important and very smart that he can actually handle a tool that looks so terribly important and cool.
Yes, it's Fluffware. But that's what the customer wants.
Personally, I enjoy the CLI. Easy, fast, reliable, uses little to no resources, perfect. But then, I wrote that thing. I'm used to CLI. I grew up on CLI. I'm a 400 keys per minute typist. And most of all, I know what I want to do. I read manuals...
People today don't read manuals. They want to explore their software like children explore their toys. "Gee, what does this button do?" must not be from the famous last words collection when it comes to software, it's the way a lot of your users want to find out how their software works. It's appealing to the explorer in them.
So I give them stuff to explore. Make the tutorial a game. It sounds silly, allright. I know. But it sells...
It's a sad world we're living in.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
HCI (Human Computer Interaction) principles are, in my opinion, THE toughest thing to learn properly in Computer Science. It is easily the thing I struggle most with in my coding.
You can't blame programmers for being programmers. Programmers are focused on programming principles like good architecture design, good algorithms etc. But making it look good? Thats tough. It requires that the programmer not think like a programmer, but a regular old end-user who has no concept of the internals of a program.
Building programs that are usable to other developers is a joy. Building programs that are usuable for developers and regular users is an outstanding feat.