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."
Software design (Score:5, Funny)
Re:Software design (Score:2, Funny)
I think you copied/pasted this from a religious thread.
Re:Software design (Score:1)
Re:Software design (Score:3, Funny)
You believe in the user? (Score:3, Funny)
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 C
Re:You believe in the user? (Score:1)
Re:You believe in the user? (Score:3, Informative)
I think that you may have meant "Fucking pay attention" or "Pay the fuck attention." Spelling's all well and good, but it doesn't do anything without somewhat correct grammar, especially when cursing. Otherwise, you just sound like an inbred Tourette's kid.
Re:You believe in the user? (Score:2)
I stand by my statement. Perhaps you need more fucking schooling in the usage of the word fuck [edict.com.hk]?
Re:Software design (Score:1)
Re:Software design (Score:2)
Re:Software design (Score:4, Insightful)
For example, if you have a one year design process, you capture the ebbs and flows of the business over that period of time, more likely you have captured a fluid structure. Your chance of success drops dramatically.
But, if you drop in, do a rapid design with elite analysts, whip out solid, secure code with an elite team in short period of time, you gain a great often undocumented benefit: You capture the business at a discrete moment in time. You codify what is exactly happening with the company at that moment. Often, the company rallies around that codified process.
I love design - but the moral of the story is, solid, detailed design alone will not give you good software or a sucessful project.
Re:Software design (Score:2)
It's all well and good to draw a guy in a green hat on a chart. Real product design requires an
Re:Software design (Score:2)
Software Evolution? (Score:4, Funny)
Re:Software Evolution? (Score:5, Funny)
Eeeew spaguetti code! >_<
"It's a feature, not a bug." (Score:2)
"It's an artifact of intelligent design, not an evolutionary anomaly."
Re:"It's a feature, not a bug." (Score:2)
Are you sure Windows was intelligently designed?
Re:"It's a feature, not a bug." (Score:1)
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?
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.
Re:Walk a mile in their shoes... (Score:2, Insightful)
This is sort of off topic, but I'm answering TubeSteak's question. I would opine that it's because the suits don't want the engineers doing stuff that doesn't directly make themselves money. I've gotten into "trouble" before because of my penchant and ability with computers. Doggone it if I can take 2 hours and develop a tool that will save me 15 minutes a day for the next 5 years, or longer,
Re:Walk a mile in their shoes... (Score:2, Insightful)
I've seen it before myself. A lot of bosses are afraid of your tools and scripts and ideas and time-saving, with good reason:
Manager is employed to hire 5 people
Walk a mile in their shoes...shoe store. (Score:1, Informative)
The Human Side of Managing Technological Innovation : A Collection of Readings (Paperback) [amazon.com] answers that question.
Re:Walk a mile in their shoes... (Score:3, Insightful)
I happen to work for a school district. Our main (only?) job is supposed to be teaching students. Yet our administration spends almost no time asking teachers what they need to be more productive. They come out with these great initiatives that they've heard or read about somewhere and the teachers are supposed to fall in line.
Then they wonder why teachers aren't more "productive". Its quite simple to figure out. The teachers spend h
Re:Walk a mile in their shoes... (Score:2, Flamebait)
Why is capitalism (well, excluding public schools) so slow to punish idiocy? In every place I've worked, I've seen these inefficiencies from lack of communication, etc. I assumed, apparently incorrectly, that a company that behaved sanely would easily trounce such mismanaged competition. Is the mismanagement actually good management? Or is it simply impossible to have a company free of gross stupidity? The school system is a different and more depressing situation because there is little chance of comp
Re:Walk a mile in their shoes... (Score:2, Informative)
I think we try to be an understaing society, forced by lawyers suing companies for wrongful termination. Then, when you bring someone into an organization, there's a certain amount of time that has to pass while you try to make money off the person. If you pay for relocation, training, and a few months of "getting used to the company" time, you've got a lot of money invested in that person. You sometimes ha
Re:Walk a mile in their shoes... (Score:5, Insightful)
i don't understand why you bring school systems into it. i don't know where you live, but there are extremely excellent public school systems in this country. the school system tends to be as good as the community demands.
Re:Walk a mile in their shoes... (Score:2)
What they don't realize is that they're smart at playing certain made up games. If they would stick to those made up games and defer to people who are smart in other fi
Re:Walk a mile in their shoes... (Score:2)
Re:Walk a mile in their shoes... (Score:2)
Then again, I already had opinions about people who study business from tutoring math in college...
Re:Walk a mile in their shoes... (Score:3, Insightful)
Re:Walk a mile in their shoes... (Score:2)
They never care about "i
Re:Walk a mile in their shoes... (Score:2)
The engineer knows in his heart that good product means getting all the pieces done right and that any argument about what is best can be resolved by careful measurement.
The others know in their suits that correct product image will replace in the minds of unsophisticated users what the project actually does with what the image suggests it does.
To see what I mean just go through a toy store and
Re:Walk a mile in their shoes... (Score:2)
Yes it can. I've had it happen. And after a while of getting shot down, you begin to not want to bother spending the time to write up a formal, yet ultimately worthless, document.
Write a proposal, CC it to their boss.
I don't know about your situation, but a lot of folks don't appreciate it when people go over their heads.
Re:Walk a mile in their shoes... (Score:2)
Re:Walk a mile in their shoes... (Score:1)
Re:Walk a mile in their shoes... (Score:1)
Marketing wants to cover as many people as possible with the program, but the programmers want it to specialize, so you end up with MS Word which people only use 10% of its features, and those are hard to get to.
Re:Walk a mile in their shoes... (Score:2)
Re:Walk a mile in their shoes... (Score:2)
The other advantage being that if you wrote the code yourself, you don't need to get used to it in order to be productive.
I like to express this in terms of latency vs bandwidth - if you code yourself you save on latency, but if you have others to program you increase the bandwidth.
Often, in soft
Re:Walk a mile in their shoes... (Score:2)
There's a sound reason why you don't want the engineers directly talking to the customers, at least outside of highly specific cases. Engineers are valuable assets, and the time spent talking to customers is the least of the worries. More bothersome is what happens if the engineer actually hears what s/he thinks is a good idea. I dunno abou
Re:Walk a mile in their shoes... (Score:2)
http://blogs.msdn.com/jensenh/archive/2006/02/17/
It's a blog from one of the UI guys working on the new Office 12. It sounds like they're addressing all your concerns in the next version, and I'm pretty excited about it myself.
Re:Walk a mile in their shoes... (Score:5, Insightful)
This would work well if the programmer just sat down with the user, with no fixed delivery date, and they started working towards a common goal. This is similar to what you're doing with Excel and Word - you have no project manager, no "budgeted hours", no "chief architect", no "technical lead", and no "requirements design meetings". Just a problem to be solved as efficiently as it can be solved.
Unfortunately, for the programmer, you're not allowed to talk to the users (or, at least, I never have been). Talking to the end-users (actually, there are no users - they're "stakeholders". You'll never meet them.) is for the Birkenstock-wearing, ponytailed, hybrid-driving "usability engineers" the author is so slobberingly excited about. Programmers just get 1500-page "requirements documents", all written in Microsoft Word over a six-month period of review meetings. The less actual information, the better. From those specifications, the programmers are expected to fill out an Excel spreadsheet listing the "tasks" they must complete to fulfill "requirements" with such descriptions as "6.G.9.d.z. The freemulator frooble must goblify the cooblestocken whenever the user selects the remulize option". No asking the "stakeholders" what that actually means - they're far too busy to talk to you. The programmer must then randomly compile a list of "tasks" and a completely wild guess as to how long each task might take. You can estimate any amount of time for any given task and add as many tasks as you like, as long as the total time you estimate adds up to the target date that the stakeholders made up out of the air without consulting you. Once the task list is complete, the whole list is handed over to a project manager who "manages" each task. He does so using sophisticated project management techniques he learned in a one-hour training seminar such as: requiring all programmers to attend a weekly two-hour status meeting where he solemnly reads the list of tasks, one by one, and says, "what percent complete are you on this task?", and "you're falling behind on these tasks. Can we offload some of these to somebody else?". Tasks can never be added or deleted once they project manager "finalizes" his Excel spreadsheet.
At the same time, the stakeholders will change their minds daily. They'll randomly remove one of the 20,000 requirements (the one you spent the last three months coding for) from the requirements list and announce that they've "flexed the scope" to meet a new "compressed delivery date" (which is next Friday).
Slowly but surely, in spite of all the obstacles that have been placed in your way in the name of improving "Product Design" efficiency, you (the programmer) will finally start to understand what it is the users might actually want and what this thing actually does. Unfortunately, about the time you see exactly what needs to be done and the best, most flexible way to do it, the "two months past code complete" date will be hit. Then you will enter "crunch time". The weekly two-hour meetings will change to daily three-hour meetings. One of the agenda items on each meeting will be to discuss how to improve programmer productivity. To make up for the lost time spent in these meetings, you'll be required to work on the weekends. Fifty new programmers will be added to the effort to "help". You'll spend 10 hours of your 16 hour day getting them up to speed. At this point, you do whatever the hell it takes to get this monkey off your back.
Then, at the end of the year, after months and months of 80+ hour work weeks, a failing liver from your increased alcohol consumption (it's the only way you can actually manage to fall asleep) and a divorce since your wife and kids can't remember your first name or what you look like, the users complain about the stinking pile of poo that you finally were able to produce in spite of the "efficiency experts" driving the process. You see, you nee
Re:Walk a mile in their shoes... (Score:2)
Re:Walk a mile in their shoes... (Score:3, Funny)
And then an anonymous coward says, "Well, you should have said no", so you hunt him down, tie his hands behind his back like Kevin Spacey did to that fat guy he made eat the spaghetti sauce in "Seven", and force him to implement a fully SOAP and BPEL compliant Web Service-based SOA solution. In Lisp. Using Notepad. On Windows 3.1. In a shared cubicle.
I've found... (Score:2)
Extreme Programming (Score:5, Insightful)
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.
Re:Extreme Programming (Score:2)
StarvingSE? (Score:2)
Re:Extreme Programming (Score:2)
Scrum [controlchaos.com] is another development process that attempts to address the "silo's of expertice" problem.
Re:Extreme Programming (Score:2)
Re:Extreme Programming (Score:2)
You got me on the spelling error. To answer your first question, you should just RTFA.
Re:Extreme Programming (Score:2)
Re:Extreme Programming (Score:2)
Ah, you're not technical. That explains the spelling correction. Here is the relevant excerpt.
The companies that survived the influx of designers and marketing folks often relegated the survivors to their own separate silos. Marketing people got one org tree, developers got another. Artists and usability folks in most cases were shoved in random back corners to rot in b
Re:Extreme Programming (Score:2)
Re:Extreme Programming (Score:2)
Nice theory.
The non-technical user, by definition, does not know what is practical for the software to accomplish, and will likely overestimate or underestimate what it
Re:Extreme Programming (Score:2)
What I'm talking about is when a company contracts a software developer to create some in-house software for them, where the user base is a great deal smaller and can more
User Centric Design! (Score:3, Interesting)
The author has no clue... (Score:5, Insightful)
"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?
Re:The author has no clue... (Score:3, Insightful)
Hmm (Score:3, Funny)
Hmm???
Re:Hmm (Score:3, Insightful)
Re:The author has no clue... (Score:2)
The idea is that the early computer *users* were generally also *programmers*. There were no non-technical computer users in the early days.
The vast majority of the history of unix is people writing software for other programmers.
Re:The author has no clue... (Score:2)
The idea is that the early computer *users* were generally also *programmers*. There were no non-technical computer users in the early days.
Yes I gathered that from the article. I just disagree with this idea. As the original post said, computers were also used for calculating missile trajectories, count census figured, etc. Not everyone using and interacting with the computers was a programmer.
Oh THAT kind of Product Design (Score:3, Interesting)
Comment removed (Score:5, Insightful)
Re:Can it really be engineering right now? (Score:2)
There's some pretty bad hardware out there. Uncomfortable chairs, sofas that cause back problems, counters at the wrong height, non-intuitive controls, etc.
Ummm, you mean just like a paper? (Score:2)
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 c
Re: (Score:2)
CS Curricula (Score:2)
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 m
CS 101 (Score:2)
So what I'm thinking is that these classes should be changed
Re:CS Curricula (Score:2)
CS - computer SCIENCE. Does or applies science. Software ENGINEER - builds software. Fortunately they're getting that sorted out now.
Re:Can it really be engineering right now? (Score:5, Insightful)
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.
I think there's a lot of truth to this. Design requirements changing in the middle of development, or being extremely vague is a killer. It's like someone making a building and saying "I want this building to have between 1 and 3000 bathrooms"). Clearly that's insane.
Re:Can it really be engineering right now? (Score:2)
Let's say you're writing analysis software. Every time you do analysis, your results inform you as to what you have learned, what you haven't, and what you can do in addition to take the next step?
This is the world of scientific computing, and it is always in flux. Analysis changes, because you're designing new methods as you go. You may add completely different sets of data as you go. Your needs may change dramatically over the course of the work.
How c
Re:Can it really be engineering right now? (Score:2)
Yes, but that takes time, and time spent is market window closing.
It's a fine approach when developing for one's self because the "market window" does not close (except if what you need suddenly becomes available elsewhere, in which case, you-the-customer doesn't care that you-the-developer was too late).
One would think that it is also fine when developing for a customer
He needs a new diagram at the end (Score:3, Funny)
Sorry to disappoint you... (Score:2)
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.
Re:Sorry to disappoint you... (Score:2)
The difference is, in bigger companies, there are always people who learned how to label utter failures to success, for the sake of their career, leading to generations of users and programmers having to deal with it making their lifes worse.
In smaller companies, an utter failure leads to closing down (and that happens a lot!) and severley hitting/damaging/destroying the lifes of those involved in the company.
In open projects an utter failure leads to a "So wh
Article text (diagram captions) (Score:2)
"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 gu
Huh. (Score:5, Insightful)
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.
Re:Huh. (Score:2)
They may be self-obvious to anyone involved the software INDUSTRY, but what about those involved in Open Source development?
User: Why don't you make software X more user friendly?
Programmer: If you want to change it, change it yourself!
User: But I don't know Mega-ASPython#...
Programmer: That's YOUR problem.
User:
Re:Huh. (Score:2)
User: Why don't you make software X more user friendly?
Programmer: Because it serves my needs perfectly well. You're welcome to change it yourself. I might be willing to help you, or do it for you, but I do have to eat.
User: What, you mean you won't put in hours of work for free just because I whined at you?
Re:Huh. (Score:2)
Re:Huh. (Score:2, Insightful)
The reason that it is so hard to "listen to your customers" is that far, far too often, customers don't know what they want - they just know that what they currently have is no good. I believe the comment below this advocating finding customer pains will lead to more success than trying to get any sort of reasonable story of what a customer wants.
I don't believe any customer went to Apple and said, "I want a digital music player that uses a really groovey touch sensitive circle as the user interface." T
Re:Huh. (Score:2)
Is it fair to say... (Score:2, Interesting)
Identifying user pain (Score:5, Insightful)
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.
Re:Identifying user pain (Score:2)
Of course they were wrong. They're too close to the code. They know the weak spots and work around them. They don't know that's what they are doing. It's like when you've hurt your ankle - you learn to walk in a way that reduces the stress on the injured part. Most
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.
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 mak
Think inside your user (Score:5, Insightful)
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.
Re:Think inside your user (Score:2)
Re:Think inside your user (Score:2)
Who buys the software? Techs or Marketeergoons?
What do said people want? Fluff or usability?
(Note that Marketeers don't have to use the crap they buy)
Re:Think inside your user (Score:2)
Pretty shiny stuff is great, for the product demo. When I'm using it for the thousandth time and I haven't had my coffee yet, I want usability, whether I'm a tech or a secretary. Usability doesn't mean power (CLI) necessarily either. Most of the time it means simplicity. I design stuff for doctors. I definitely don't use a CLI, but I try my very best not to use buttons either. Buttons confuse them.
HCI (Score:5, Insightful)
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.
Where the problem is (Score:2, Insightful)
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.
Next year, FIVE GUYS! Or, back to nirvana? (Score:2)
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
if it only were so simple (Score:2)
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 structur
Re:MDA (Score:3, Insightful)
So, anyone else thinking that the AC poster of the parent just might be one of the authors of the linked-to book? ;)