Software Development's Evolution towards Product Design 165
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."
Walk a mile in their shoes... (Score:5, Interesting)
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.
Re:Walk a mile in their shoes... (Score:5, Interesting)
Engineers always say that if the suits just asked, the engineers would help make everything better. The suits, in the meantime, are busy doing everything but listening to the engineers.
Why is there such a fundamental disconnect between the engineers and *everyone* else in a business environment?
User Centric Design! (Score:3, Interesting)
Oh THAT kind of Product Design (Score:3, Interesting)
Re:Walk a mile in their shoes... (Score:4, Interesting)
Because it's the only way to get any work done.
Every group usually has one person that does all the work, the rest just have meetings all day and pretend to be useful. If you're smart about it, you can sacrifice a member of the group, and they go do all the meeting stuff, and the other n-1 can actually do something. Those are the companies that win.
Is it fair to say... (Score:2, Interesting)
Product "Designers" (Score:5, Interesting)
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.
Seeya in a Couple Years (Score:3, Interesting)
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.
Re:Product "Designers" (Score:2, Interesting)
There are solutions to the (very real) issue you describe. For example, at Microsoft, the role I'm in as a Program Manager is meant to bridge gaps just like this one. I act as something of a technical liaison between my division's User Experience team (usability engineers, product designers, and interaction designers) and developers and PMs.
Once you have someone in a role where their entire job focuses in on ensuring that necessary conversations and information transfer occur it becomes much easier to make headway and avoid confusion between the Ux and Dev camps.