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'
"It's an artifact of intelligent design, not an evolutionary anomaly."
An Indian-American Hindu committed to non-violent thought/speech/action alarmed by the global explosion of radical Islam
That's the official name for it. Universities have been offering courses in it as part of HCI (Human Computer Interactions) for a while now.
"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?
I was thinking of the other kind of actual Product Design that we're also evolving towards. :)
Power to the Peaceful
RAM: "You believe in the user?"
Crom: "Sure I do! If I didn't have a User, than who wrote me?"
RAM: "That's what you're doing down here. Master Control Program's been snapping up all us programs who believe..."
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.
There needs to be a new little diagram called 'The Open Source Era'. It would start with the programmer throwing the 'Biz Guy' out the window. Then he'd put up a wall labled 'Skinning' between him and the 'Designer' and the 'Interaction Dude' and going back to work.
set softtabstop=4 shiftwidth=4 expandtab nocp worlddomination
I. Golden age: The technocrat era
"We make stuff for ourselves, whee!"
Programmer has a technical need.
Programmer creates product that fulfills the need. The other programmer is happy!
II. The early business era.
"Holy crap, we can make money!"
Biz guy ($) notices that a customer has a non-technical need.
A team of programmers is assembled to create a product.
They produce a pile of poo* for the Customer.
* the product is technically correct, but doesn't address non-technical issues.
III. The late business era.
"I guess we need some of that touchy feeling junk. Should be easy."
A team of programmers and artists* come together to solve a customer need.
* Folks who understand the emotional needs of the customer. These may be designers, subject matter experts, etc.
Pain! Artists are insane and programmers suck.
Progress! Together they produce a better pile of poo* for the customer.
* The product addresses some technical and some emotional needs. But it tends to be mangled in translation.
IV. The product design era.
"The 'touchy-feeling junk' is the main reason why people are buying our swag!"
A team of WISE programmers and artists (biz guy, designer, interaction dude, programmer) comes together to solve a customer need.
1: Adopt DESIGN TOOLS for software development.
2: Create a PRODUCTION PIPELINE for the whole team.
3: Work as a cross functional team to create an amazing* product.
* The product addresses technical, economic and emotional needs. Wow!
Just chipping in as an Informatics major at the University of Washington. It's all about understanding that while users may be dumb^H^H^H^H^H^H^H have different priorities, programmers can't afford to ignore them and spout things like "They adapted to that, they'll adapt to this. And it's cool!"
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.
...that linux is in "The Early Business Era" (stage 2)? When some distros like Ubuntu actually pay for and sponsor usability studies, I'd say Shuttleworth has this distro uniquely placed in "The Late Business Era" (stage 3). So, just grab yourself a middle man (for example) who scours linux forums for window migration user problems, relaying them back to the devs and artists, and that polish will become apparent in "The Product Design Era" (stage 4).
I hope, when they die, cartoon characters have to answer for their sins.
but most open source software *cough* GIMP *cough* is still in the "technocrat" era. They just don't care for the end user, they worship the product in itself.
Sad to say it, but successful open source products (OpenOffice, Firefox) are the exception, not the rule. And yes, I know what is being an open source developer.
"Why is there such a fundamental disconnect between the engineers and *everyone* else in a business environment?"
The Human Side of Managing Technological Innovation : A Collection of Readings (Paperback) answers that question.
So why is it that all these engineers wrote all of their ancient programs in COBOL?
Hmm???
That's "Mr. Soulless Automaton" to you, Bub.
A new diagram at the end? How about three dozen AI diagrams?
AI Algorithms Steps are the latest in software design for open-source artificial intelligence (AI).
AI Theory of Mind opens the doorway for programmers to cash in and launch life-long careers in the burgeoning field of artificial intelligence.
Diagrams of Artificial Intelligence teach the theory behind the design of artificially intelligent software.
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.
Aren't we all taught that when we are writing a paper we're supposed to sit down and plan it out first? That we're supposed to create an outline?
In the end, the structure and design that preceeds coding correlates to the nature of the task, just like it does with writing a paper. Writing an e-mail, or posting on a blog is not an intensive literary endeavor, so no need to come up with a thesis, outline, etc. Writing a quick script to move some files around, etc, also doesn't require use cases, and state charts. To apply that amount of order would make the whole thing take a lot longer with not substantial benefit.
But if you're writing a doctoral thesis, yeah you'd better sit down and get yourself organized. What's your thesis? What's going to be the order in which you make your arguments? It's important and large so you need to spend some time designing it. If you're doing mission critical enterprise software, you do need to sit down and plan things out in detail, especially if you're dealing with a group of developers.
Now, as for the comparison to the way cars are built, I think this tendancy to relate software development to physical world engineering is a mistake. The main reason being that an item in the physical world can't be recompiled, or patched, or in any way modified once it's put together. Software is malleable, everybody knows it, and so pretending otherwise is just creating misery for one's self.
This is one of the reasons I like the Extreme Programming methodology. It seems to account for the malleability of everything decently well. You're always dealing with discrete chunks of functionality in short time intervals. It assumes that refactoring is going to happen and should happen frequently. Try refactoring a car... actually don't, you'll void the warranty for sure. You can try to design a complex system to deal with every little last possible requirement but it will take you forever to do this and in the end you'll have to change it anyhow.
In a perfect programming world, all of the requirements for a product would be known up front and never change. Design could be quite solid and implementation would be a breeze. I've NEVER seen that in the real world. In the real world, you are given a rough idea of how it should work and then it's changed several times while it's being written.
This sig has been temporarily disconnected or is no longer in service
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.
Phase one, the developers worked with the users (hell, they WERE the users). Every phase since then, there is someone bewteen the programmers and the users, claiming that they know what the users want. Perhaps we should get rid of those guys, and let the programmers and users work together again?
I'd rather take advice from someone with the username "WellFedSE" ;)
Most people never really get exposed to serious writing. I admit that I have little, very high-level experience in that area. Most of the work that I was assigned in college on writing, I could do the whole thing in one sitting, including successfully arguing my thesis. Really well-researched writing is hard to do, and something that most people don't get meaningful exposure to, so I think my analogy stands.
In all of my real writing classes in college, I got As without even trying. Once you learn how to express yourself consistently and build up a base of good spelling and a functional knowledge of proper grammar, it's not hard.
The root of the problem is that the average person can get by easily without having to go through the planning stages. Once you reach a level of proficiency, you can skip them, but most people never develop that. I developed enough of one with software design that I could do semester projects in a very organized way for classes without much prior planning. That comes from a few years of experience. The solution, as I see it, is to force people to really get their hands dirty with planning and structure. That might make people have at least a modicum of appreciation for software development.
Robert G. Cooper, a well known researcher on new product development, states that there are several core factors (listed in order of importance) for any successful new product design process:
1. A unique, superior and differentiated product with good value-for-money for the customer.
2. A strong market orientation - voice of the customer is built in
3. Sharp, early, fact-based product definition before product development begins
4. Solid up-front homework - doing front end activities like market analysis well
5. True cross functional teams: empowered, resourced, accountable, dedicated leader
6. Leverage - Where the project builds on business's technology and marketing competencies
7. Market attractiveness - size, growth, margins
8. Quality of the launch effort: well planned, properly resourced
9. Technological competencies and quality of execution of technology activities.
Many companies in the Late Business era already emphasize a few of these factors. However, there are some differences. Notice how technical competencies are important, but last on the list. Notice also, how that creating a solution to customer needs is first on the list.
I look forward to seeing the resulting products in a couple years. Five years ago I started on a project that was initially focused on technical proficiency. Then a shift occurred. For the last three years the only thing that was allowed to guide work was customer feedback (I switched projects about two years ago). Technical profiency of the developers for the past three years has been considered nice, but not critical. Technical CRs were explicitly disallowed by the project management. It is a multimillion dollar application suite pushing two million lines, which is the primary application of about 8,000 people - roughly half our labor force. It is currently under review and may be scrapped.
Why? Because the code is dying. The features are there, and it looks good, but it is extraordinarily expensive to maintain, is overly tolerant of corrupt data, and every time someone looks at it funny it breaks. Adding new features has become an exercise in chasing an induced bug through dozens of classes.
The initial approach of technical isolation was wrong - we needed closer contact with the customers and it would have made the product much better earlier in the lifecycle. Now, however, it is precisely the lack of technical proficiency that is killing it. Relegating the user experience or the infrastructure to the back seat is a road to ruin. There is no point in creating software that doesn't solve the customer's problem. But there is also no point in creating software that is more costly than the problem the customer is trying to solve. Discounting technical proficiency is a direct path to cost-ineffective solutions.
Stop-Prism.org: Opt Out of Surveillance
I think the big problem is that CS, as it's been taught is far more about the the theory of writing code and less about the real world design of software. In CS I learned about bubble sort. You know how often I use bubble sort? Never. Why? Because either my data is sorted when it comes out of the database or it's sorted using methods built into the language I'm using.
The vast majority of software that is written is done at a very high level right next to where business process and decisions are being made. Resource allocation, requirements gathering, and design, are what's critical to these projects succeeding, not the quality of the sorting algorithm used. It is important as a programmer to have an understanding of general algorithms and why some ways of doing something are better than others. But by and large, most of the serious problems I've seen in software development are rooted in the higher level issues of design.
This sig has been temporarily disconnected or is no longer in service
I was just thinking that what would be interesting to see is change to what CS 101 classes typically are. My CS 101 was a pascal class (yeah, old skool). It was a class that many non-CS people would take to fulfill a computer requirement in another department. CS people usually found it painfully easy and non-CS people often struggled. Not many people go into CS without that basic knowledge of programming picked up somewhere else along the way.
So what I'm thinking is that these classes should be changed from raw programming to more of a design class. Like what if you spent a semester teaching people how to do analysis and documentation instead of teaching them how to write a for loop? The majority of people in this world don't need to know how a for loop works. But giving them some insight into how a business need can be broken down into specific concrete requirements would be hugely beneficial even beyond CS.
This sig has been temporarily disconnected or is no longer in service
Heh, take a look at the guy's final diagram. Programmers are at the end of the chain. The poo hasn't disappeared from the process, it's just that now all the poo is upstream of the programmer and it's up to him to juggle it until it doesn't look like poo anymore.
Steve
A work that expires before its copyright never enters the public domain and thus enjoys eternal copyright protection.
I've found that when developing a new application, 90% of the meetings and design time are taken up with the task of getting the end user to understand what it is that they do. It is very common for companies to run with a process of each person just doing their own thing. They often having no real idea as to what the end product needs to be, or what supporting data they need to get their. When working with groups that know their job, and are not just winging it every day, the software comes out much better.
Of course when the end user does not understand what they need, AND the developer doesn't listen anyway, you are really in trouble.
Hint - the programmers throwing the baby out with the bathwater rarely results in a successful product - the other reply to yours about the GIMP does indeed apply quite nicely here. Why exactly did Photoshop top the Novell list of "I wish I had it on Linux"? Oh yeah. Because it does what the Adobe "Biz Guy's" (multiple levels of them, surely) discovered customers actually wanted. Otherwise you end up playing a game of telephone (surely you remember that from your childhood) as software development. Which doesn't bode well for any product's success (software or otherwise).
Programmers and Designers have a vested interest in being fairly familiar with the others discipline. I don't believe there is generally enough emphasis on design in computer science or for that matter programming principles in designer's curriculum.
That being said I think that what is often over looked is that bringing organization and hierarchy to today's stateless AJAX apps is imperative and that in consideration of this organization is also very helpful for the programmer to be cognizant the type of design wanted and personally have a solid grasp of layout. Even when putting together something as simple as a registration form, logical placement of the elements out of the gate can't help but give an app a leg up.
From a design perspective, because consumers are so inundated with software tools to potentially use, apps that do not offer a low barrier to entry, enabling quick pick up of the most important features, are also-rans.
Making software work easily makes it useful that is why it makes business sense. Making software look good makes software easy to use.
The CRAP Principle (applying them improves any design):
C - Contrast
R - Repetition
A - Alignment
P - Proximity
Use it - don't abuse it.
If you'll notice from the text near the end of the article, it's nothing more than a viral marketing piece pushing Microsoft's upcoming "Expressions" suite of products, which aim to make the Web even more proprietary in nature.
Microsoft has been getting its employees out there, pushing their version of Jonestown Kool-Aid, masqueraiding honest-to-goodness bloggers. It's just marketing and you all got suckered in.
So, adding a user interface designer to the picture is going to keep the customer from getting poo? I don't believe it for a second. Next year, they're going to add an application specialist because the problem is that none of the people in the chain know what the customer actually wants.
So instead of getting pretty poo, he'll get pretty *square* poo. At least it's easier to stack.
The real problem is that back in the "Golden Age", the customer was involved in the software development. In all the rest of the pictures, the customer is this unhappy blue guy off to the side... all the happy guys are on the LEFT side of the picture: if you're only on the right side, you know you're going to get poo.
So, take that blue guy, and stick him on the right.
That way, at least if he gets poo it's his own damn fault.
83% of statistics are made up...
use const NUM_BATHROOMS => 3000;
...
#use const NUM_BATHROOMS => 1;
map {$_->flush} @bathrooms; #-- this code: clearly insane
Algorithms for Artificial Intelligence include the Human-Computer Interaction (HCI) mind module.
The Human-Computer Interaction module is a two-way street between the AI Mind and the human user.
Mentifex AI Theory explains how the HCI module fits into a Theory of Cognitivity for artificial intelligence.
The Theory of Cognitivity is the theoretical basis for the Human-Computer Interaction (HCI) mind-module.
> At the dawn of software history, programmers wrote software for other programmers. This was a golden era. Life was so simple.
And nowadays they set stupid^H^H^H^H^H^Huneducated poeple use computers... tz tz...
You don't let uneducated poeple operate on you or fly your plane, do you?
And we all know a computer is the second most complex machine on planet earth (right after the animal [expecially the human]).
I guess this will change in the next decades*...
* hint: NOT because computers become smarter
Any sufficiently advanced intelligence is indistinguishable from stupidity.
Bringing marketing and product designers into the software creation process doesn't change anything: those people aren't any more concerned with solving the user's problems than programmers, they're concerned with selling stuff. And that's assuming that they are any good, which most marketing and designer types aren't.
Creating a great product requires the right kind of people, the right kind of management, and a great deal of luck. Anybody who thinks he can reduce it to cookie-cutter organization structures is a complete fool.