Beta

Slashdot: News for Nerds

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Software Development's Evolution towards Product Design

Zonk posted more than 8 years ago | from the more-than-just-guys-in-a-cube dept.

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."

cancel ×

165 comments

Software design (5, Funny)

nizo (81281) | more than 8 years ago | (#14743352)

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.

Re:Software design (2, Funny)

imstanny (722685) | more than 8 years ago | (#14743377)

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 think you copied/pasted this from a religious thread.

Re:Software design (1)

Dragoonkain (704719) | more than 8 years ago | (#14743381)

intelligent design saves people from thinking about the software creation process at all

intelligent design? creation process? hmmm sounds familiar..

Re:Software design (-1, Offtopic)

Anonymous Coward | more than 8 years ago | (#14743395)

You're so funny how you worked "intelligent design" into your post so many times! It's classic! LOL. I'm dying here - OF LAUGHTER. Seriously, have you considered comedy as a living? 'Cause your materiel is sheer gold baby. You can take that to the bank!

Re:Software design (1)

adinu79 (860333) | more than 8 years ago | (#14743412)

hmmm ... inteligent design seems to creep into software development as well. Time to change my field of work.

Re:Software design (2, Funny)

$RANDOMLUSER (804576) | more than 8 years ago | (#14743480)

Actually, I put in some features to decieve you - to test your faith in the software.

You believe in the user? (2, Funny)

Tackhead (54550) | more than 8 years ago | (#14743494)

> 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.

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..."

Re:You believe in the user? (1)

skoaldipper (752281) | more than 8 years ago | (#14743690)

May the Tron gods who read this bestow upon you a multitude of mod points in their almighty musings...

Re:You believe in the user? (0)

Anonymous Coward | more than 8 years ago | (#14743947)

Crom: "Sure I do! If I didn't have a User, than who wrote me?"

Than != then. Pay fucking attention.

Re:You believe in the user? (2, Informative)

PitaBred (632671) | more than 8 years ago | (#14744044)

Than != then. Pay fucking attention.
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? (1)

heinousjay (683506) | more than 8 years ago | (#14744093)

Pay the fuck attention.

LOL, what?

The OP's phrase was clunky, but this one reads like an ESL* student's first hissy fit.

(* English as a Second Language)

Re:Software design (-1, Offtopic)

Anonymous Coward | more than 8 years ago | (#14743526)

Sometimes I put my hand down the back of my pants, and pass wind directly on my bare hand. So I can feel the wind. Then I raise my hand to my nose, and sniff it. I deeply inhale. And the bouquet of the fermented feces in my bowel awakens my creativity. I am being 100% serious. I am posting ac because i know that some people won't appreciate my methods.

Re:Software design (-1, Offtopic)

Anonymous Coward | more than 8 years ago | (#14743717)

Yeah, I smell my hand after I scratch my balls. I don't know if it affects my creativity though...

Re:Software design (1)

Fr05t (69968) | more than 8 years ago | (#14743835)

Oh hey there Mr. Thompson! I always wondered where you got all your great ideas from.

Re:Software design (0)

Anonymous Coward | more than 8 years ago | (#14743534)

The catholic church called, they want their propaganda back.

You Have No Rights or Constitution: +1, Helpful (-1, Offtopic)

Anonymous Coward | more than 8 years ago | (#14743749)



in the United Gulags of America [whitehouse.org] .

Defend America: Detain The White House !!!

Patriotically,
Kilgore Trout, C.E.O.

Re:Software design (1)

ketsugi (930099) | more than 8 years ago | (#14743770)

Does this necessarily mean that software design and product design, like intelligent design, are in no way "science"?

Re:Software design (1)

ceoyoyo (59147) | more than 8 years ago | (#14744212)

Yes, yes it does. There's not a whole lot of rigorous scientific method applied to either of those disciplines. Much more "the book said so."

Re:Software design (1)

jinzumkei (802273) | more than 8 years ago | (#14743828)

In fact, intelligent design saves people from thinking...

Funny, I thought the same thing about ID.

Re:Software design (3, Insightful)

Heembo (916647) | more than 8 years ago | (#14744240)

Something I hear few say, is that a LONG design process can be very dangerous to a projects success.

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.

Software Evolution? (4, Funny)

n6kuy (172098) | more than 8 years ago | (#14743370)

Momma told me software was created by Flying Spaghetti Monster...

Re:Software Evolution? (4, Funny)

Spy der Mann (805235) | more than 8 years ago | (#14743403)

Momma told me software was created by Flying Spaghetti Monster...

Eeeew spaguetti code! >_<

"It's a feature, not a bug." (1)

GillBates0 (664202) | more than 8 years ago | (#14743468)

or in present-day parlance:

"It's an artifact of intelligent design, not an evolutionary anomaly."

Re:"It's a feature, not a bug." (1)

dc29A (636871) | more than 8 years ago | (#14743482)

"It's an artifact of intelligent design, not an evolutionary anomaly."

Are you sure Windows was intelligently designed? :)

Re:"It's a feature, not a bug." (1)

MajinBlayze (942250) | more than 8 years ago | (#14743553)

Are you sure Windows was intelligently designed? :) It certainly doesn't follow "Survival of the Fittest" rules

Re:Software Evolution? (0)

Anonymous Coward | more than 8 years ago | (#14744001)

So it is you, who writes all that spaghetti code!

Walk a mile in their shoes... (5, Interesting)

Quintios (594318) | more than 8 years ago | (#14743418)

That's one of the things I've found most interesting in my n00bie programming travels. As a chemical engineer, I find that the programming I do (mostly scripting for automating Office and text manipulation to get stuff into Excel, or Word, etc.) serves me and my buddies quite well, but the solutions developed by central IT are usually complicated, buggy, and just plain awful. They seem to have little idea of what *our* (the engineers) workflow/work process is.

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... (4, Interesting)

TubeSteak (669689) | more than 8 years ago | (#14743471)

You sound like every engineer I've ever talked to.

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... (3, Interesting)

Duncan3 (10537) | more than 8 years ago | (#14743562)

Why is there such a fundamental disconnect between the engineers and *everyone* else in a business environment?

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... (2, Insightful)

Quintios (594318) | more than 8 years ago | (#14743596)

Why is there such a fundamental disconnect between the engineers and *everyone* else in a business environment?

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, why shouldn't I?

Cause it's not my job. :(

I think also that perhaps the suits look down on us in some ways for being overly excited about equations, calculations, and being just really really anal and annoying at times when things aren't *exactly* right. In my line of work if you're not careful people get killed. I *have* to be this way, but in the end I enjoy it. :)

In the same respect, there's a lot of engineers out there that don't care about the nifty tools I develop. Probably because they're not really that nifty, but in the end a few of them have gotten distributed. Some people are very "toe-the-line" and if it's not an official company-sponsored work process or tool, or they didn't get training on it, they won't touch it. A lot of engineers have blinders on when it comes to their work, which is bad because what if a better widget comes out? You have to stay abreast of current and future technology.

I could continue to ramble, but in the end I think we're all paid to do different things. The suits run the business deals and make sure the engineers are working towards making those deals successful, and the engineers are always looking to improve things. Anything. Everything. Whatever they can touch. Well, at least, that's *me* doing that. :)

Re:Walk a mile in their shoes... (3, Insightful)

cwgmpls (853876) | more than 8 years ago | (#14743616)

It's not just engineers. It is the worker bees in any organization.

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 half of the time jumping through hoops that the administration has set up, rather than the administration providing what the teachers need to do their job.

Teachers know how to teach, engineers know how to engineer, what the suits are supposed to do is listen to what those people need and provide it for them.

Instead, and especially with IT, the administration thinks they know it all and can tell the teachers what to do. It should be the other way around!

Re:Walk a mile in their shoes... (1, Flamebait)

fossa (212602) | more than 8 years ago | (#14743951)

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 competition. My mother and friends work in public schools and have many horror stories about administration mandating the latest and greatest "programs".

Re:Walk a mile in their shoes... (1)

maxume (22995) | more than 8 years ago | (#14744031)

Half of all people are below average...

There is an interesting article or blurb(that I can't find) in Fast Company that makes the point that as organizations grow and begin to do more stuff on paper, they are infiltrated by people that are adept at pushing paper, but little else. Since they are good with paperwork, they navigate the organization well and advance/survive.

This is one aspect of Gore that I find interesting, they completely eschew hierarchy.

Re:Walk a mile in their shoes... (2, Informative)

Quintios (594318) | more than 8 years ago | (#14744035)

We're slow to punish people for several reasons, I think:

  1. Lawyers
  2. Invested capital
  3. Circumstances

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 have to wait to see if it pays off. And then we also try to take into account the circumstances of the individual, or at least I hope we do. If that person is going through some personal trauma, we try to take that into account if they are going through an unproductive period. Of course, if #2 and #3 happen at the same time there's not much of a future for you at the company. :(

Now, if it's been verified that you are indeed an *idiot* and management knows it, you won't be around long...

Re:Walk a mile in their shoes... (4, Insightful)

mattkime (8466) | more than 8 years ago | (#14744246)

bah, success ALLOWS for idiocy within a company. success isn't being as streamlined as possible. success is selling a product.

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... (1)

ceoyoyo (59147) | more than 8 years ago | (#14744374)

Capitalism depends on people who hold capital (money). So if you're smart and you have an idea, you need some of that money, which means you need some of the capitalists. Capitalists like to think they're smart (they have lots of money, right?). Since they're so smart, they should tell you what to do. Guide you. Manage you. So they do.

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 fields, everything would be fine. But they don't. Nobody wants to admit they're not smart at everything.

Re:Walk a mile in their shoes... (2, Insightful)

ChilyWily (162187) | more than 8 years ago | (#14743906)

In addition to many good points, the reality is that once a company achieves a certain reputation and a product (which is doing reasonably well.. even in appearance), then *everything* becomes a 'business case'. It is for that reason that so-called 'Leadership' comes from getting as much revenue as possible out of the said product... Engineering types are usually kept out of the loop - because typically they see through all this BS. Sad part is that most of them, especially the technically and intellectually capable Engineers ones don't engage themselves to the next level - so the business types implicitely take over control - then begins a long cycle of reaching SEI levels and process where as the real money, innovation and most of all, creativity, which fueled all the initial success is lost.

bleh.

Re:Walk a mile in their shoes... (1)

JohnnyBigodes (609498) | more than 8 years ago | (#14744264)

Simply because "they" themselves do not know what they're looking for. The latest buzzword or what is going around or where the "market" is heading is the only objective, the means don't matter at all. What they have is a concept of a "product", and a "market". The market needs carrots, so they tell you to make carrots (who cares if they themselves don't know what a carrot is?). Even if said carrots are off-coloured, rotten on the inside, and with little insects crawling out of them.

They never care about "insignificant details" because that would take away focus from the next big product, and if people start understanding that those carrots are awful, they spend all their time making them LOOK better instead of actually improving them.

Bottom line, after this little rant... too much abstraction is the management/marketer/whatever's problem. It's the old adage of "get it done, and don't give me bullshit. I don't care HOW it's done, just do it!". They know the company should have something done, and they find out what's the name of that "something", and that's it.

The businesses that are actually successful are the ones that can keep the fine balance between "the product" as an abstract concept, and "the product" as a practical application.

Re:Walk a mile in their shoes... (1)

Ruie (30480) | more than 8 years ago | (#14744417)

Why is there such a fundamental disconnect between the engineers and *everyone* else in a business environment?

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 then through Best Buy.

And, just to be precise, by "unsophisticated user" I mean one that does not go to the specs and does not try to characterize the product in a somewhat rigorous fashion.

Re:Walk a mile in their shoes... (1)

DesiGuy421 (782201) | more than 8 years ago | (#14743599)

You've just described the entire goal of Software Engineering and its process.

Re:Walk a mile in their shoes... (1)

jaweekes (938376) | more than 8 years ago | (#14743709)

I think that another problem is that the marketing people and the software programmers do not agree about whom the target audience is, or what their needs are.
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... (1)

StarvingSE (875139) | more than 8 years ago | (#14743932)

And sometimes the marketing people will go off and sell features that aren't feasible for the software people to include, or will take too long / be too expensive. In the end it makes the software team and quite possibly the company as a whole look pretty bad.

Re:Walk a mile in their shoes... (0)

Anonymous Coward | more than 8 years ago | (#14743765)

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.

While I agree with this general idea, I have found that *a lot* of the time people find their own code better that others because, well it's theirs. If I had a dollar for everytime someone told me, "I wrote this great software! All you do is copy and paste this key word from my personal notes into this unlabled text box in this un-named window which is automagically lauched when you plug in a flash drive with the same serial number as mine! Then just hit ctrl-alt-shift-my-kids-birthday and it will populate the database for you! Well, as long the database is named in memory of my dead cat and..."

Sure, he understands his requirements better than anybody, and his software works great for him... but it's not a "better product". It's a custom tool...

Re:Walk a mile in their shoes... (1)

Ruie (30480) | more than 8 years ago | (#14743908)

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.

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 software or science having smaller latency trumps bandwidth in a big way.

Re:Walk a mile in their shoes... (1)

DingerX (847589) | more than 8 years ago | (#14744051)

I'm always fascinated by the different uses people put to software, and perpetually annoyed by the assumptions some designers have in how I'm going to use stuff as well.

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 about you guys, but for me, a "good idea" coding-wise is one that involves an interesting solution, or does something really cool, or otherwise sierra hotel. Heck, I might run off and spend two weeks on it. So someone -- a producer, say -- has to act as a filter and determine what is worth doing, and what isn't.

Of course, this also means that the boss in charge doesn't always have a clear notion of what's important to anybody. In fact, they usually don't.

But back to the point: designs often make bad assumptions about their demographics, often because A) They misconstrue their target demographic and B) they overrely on focus groups.

Take Microsoft Office: has anyone ever looked in detail at the crap that's in there? There's all kinds of junk for "generic business settings". Guess what? Most of Microsoft Office usage doesn't occur in Generic Business Settings, and when it does, the business users are neither sufficiently educated nor interested to use all those features. Themes? Who writes a word document with themes? But, well, the target demographic of businessfolk says "we want to be able to do all these business-things", and so now you have a good two dozen themes for Microsoft Word, along with auto-bulleting, numbering, and every other way to add meaning to the structureless drivel that pollutes our businessspace.

It's not that hard:
A) Figure out what people want, technically and emotionally.
B) Make it simple
C) Make it pretty.

But A) seems a mystery to most software designers. Then again, so does the opposite sex.

Re:Walk a mile in their shoes... (5, Insightful)

computational super (740265) | more than 8 years ago | (#14744311)

They seem to have little idea of what *our* (the engineers) workflow/work process is.

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 need to have ten layers of project management because it's too inefficient to just put the programmer next to the user and say "Figure out what they need and do it. You're done when you're done". You get a negative performance review from your boss du jour (who was hired last week to replace the latest of the eight bosses you went through last year all of whom are now vice presidents of something or other) for not performing a "gap analysis" at the beginning of the project and identifying the "design flaws" early on.

Then, you read an article about how programmers are the least important part of programming, written by a "designer" who says, towards the end, "Notice how 'technical competence' is at the bottom of this list?" You track him down and kill him. Then you go to jail. And it's hard to find out what "*our* (the engineers) workflow/work process is" when you're in a jail cell where you can't get a pencil because it's to sharp and might be used as a weapon.

I've found... (1)

Belial6 (794905) | more than 8 years ago | (#14744398)

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.

Natural. (-1, Redundant)

Anonymous Coward | more than 8 years ago | (#14743423)

I believe the article writers meant 'micro-evolution', not 'evolution'. Not once has a 'half software, half product' transitional form been observed in the fossil record.

Extreme Programming (5, Insightful)

StarvingSE (875139) | more than 8 years ago | (#14743445)

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.

Re:Extreme Programming (1)

$RANDOMLUSER (804576) | more than 8 years ago | (#14743537)

I think that extreme programming calls for "extreme user interviews" first. Maybe rubber hoses.

Re:Extreme Programming (1)

TastesLikeChicken (54530) | more than 8 years ago | (#14743885)

XP allows the code to be of higher quality, and it ensures that the UI will not be horrible. XP won't help create an innovative-intuitive UI that users will enjoy using.
Developers are really good at something most people can't do at all, writing software(writing instructions for a non human that only understands explicit-logical- written instructions). Developers are not designers.
By the time an XP team has a first version of thier UI together they've already begun locking themselves into a way of doing things. There is a resistance to change existing UI code (last time I checked UI was pretty hard to refactor).
When users write thier stories for an XP team they don't include tacit information. A 'good' designer is skilled at turning tacit information into explicit information. A 'good' designer will also go through UI sketches with users (paper prototyping, iterative development) to find out what they want before anything is commited to code (commiting things to code is expensive).

StarvingSE? (1)

roach2002 (77772) | more than 8 years ago | (#14743952)

I'd rather take advice from someone with the username "WellFedSE" ;)

Re:Extreme Programming (1)

anomalous cohort (704239) | more than 8 years ago | (#14744198)

Scrum [controlchaos.com] is another development process that attempts to address the "silo's of expertice" problem.

User Centric Design! (3, Interesting)

jma05 (897351) | more than 8 years ago | (#14743476)

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.

Informatics (0)

Anonymous Coward | more than 8 years ago | (#14743582)

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!"

Re:Informatics (1)

jma05 (897351) | more than 8 years ago | (#14744235)

As an Informatics PhD candidate myself with a HCI focus, I don't think users are ever dumb. They are just better at other things by their past experiences and have different world views from system designers. It's just the dumb programmers who dismiss what they don't understand about human cognition that find them dumb. It's a cop out by saying it's not their fault for not creating a usable system.

    As a physician myself, I see brilliant experts in their respective fields make what can be regarded as silly mistakes with computers if I put my geek hat on. But when you carefully interview and observe why they took that decision path, the results always make sense.

    It is really hard to put yourself in the user's mindset without all the assumptions that come with experience with developing systems.

The author has no clue... (5, Insightful)

xxxJonBoyxxx (565205) | more than 8 years ago | (#14743483)

"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... (2, Insightful)

Vellmont (569020) | more than 8 years ago | (#14743585)

You're right, for the most part programmers were writing software for other engineers, not other programmers. The author is using a shortcut though to describe "other people like themselves". The software programmers need is tools to create software.

Hmm (2, Funny)

ENOENT (25325) | more than 8 years ago | (#14743635)

So why is it that all these engineers wrote all of their ancient programs in COBOL?

Hmm???

Re:Hmm (2, Insightful)

Vellmont (569020) | more than 8 years ago | (#14743796)

That would fit into the second era of software design, where the guys with money thought that they (or other managers) could understand code, so they naturally wanted a language that was as much like english as possible. Thus COBOL became terribly (in more than one sense) popular.

Re:The author has no clue... (1)

Chirs (87576) | more than 8 years ago | (#14743657)


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... (1)

Vellmont (569020) | more than 8 years ago | (#14743872)


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.

MDA (0, Offtopic)

Anonymous Coward | more than 8 years ago | (#14743486)

Executable UML [amazon.com]


Executable UML is a major innovation in the field of software development. It is designed to produce a comprehensive and understandable model of a solution independent of the organization of the software implementation. It is a highly abstract thinking tool that aids in the formalization of knowledge, and is also a way of describing the concepts that make up abstract solutions to software development problems.

This timely new book, Executable UML: A Foundation for Model-Driven Architecture, thoroughly introduces, documents, and explains this important new technology. The authors show how UML can formalize requirements and use cases into a rich set of verifiable diagrams, how it can be used to produce executable and testable models, and how these models can be translated directly into code. In addition, the book explains how individual system domains are woven together by an executable UML model compiler.

The book is full of tips and techniques to help you:

        * Partition a system into subject matters based on individual aspects
        * Pick the right level for use case modeling to speed subject matter comprehension
        * Model classes and focus on relationships to capture subject matter semantics precisely
        * Express behavior using the newly adopted UML action semantics and action languages
        * Specify constraints using tags specified in OCL (Object Constraint Language)

In addition, this book tackles topics of particular importance in execution, such as how to:

        * Synchronize objects by building lifecycles using statechart diagrams
        * Model relationships and contention safely
        * Distribute dynamics to avoid unmaintainable controller objects
        * Verify the models by executing test cases against the statechart diagrams and constraints

A large-scale, fully developed case study runs throughout the book to illustrate concepts and techniques.

Re:MDA (2, Insightful)

discontinuity (792010) | more than 8 years ago | (#14743910)

So, anyone else thinking that the AC poster of the parent just might be one of the authors of the linked-to book? ;)

Re:MDA (1)

CardiganKiller (854899) | more than 8 years ago | (#14744129)

Yeah, this was cut/pasted from the book description with a little bit of editing. Referring to it as a major innovation is kind of a sham. MIT's Alloy Analyzer does the exact same things, and it's been around since 1997. The only real convenience is that it sticks to the UML standard. And who uses UML anyways? ;)

Re:MDA (1)

EMB Numbers (934125) | more than 8 years ago | (#14744160)

Ha ha. Nice one!
Executable UML... I'm still giggling. Is it subtitled "how to write 10,000 lines of code with 1 million pages of paper that nobody will ever read" ?

Oh THAT kind of Product Design (2, Interesting)

Saeger (456549) | more than 8 years ago | (#14743490)

I was thinking of the other kind of actual Product Design [worldchanging.com] that we're also evolving towards. :)

Can it really be engineering right now? (5, Insightful)

MikeRT (947531) | more than 8 years ago | (#14743519)

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.

Re:Can it really be engineering right now? (1)

Chirs (87576) | more than 8 years ago | (#14743679)

"If people would treat their programs more like engineered pieces of hardware than written works in progress, things would be better."

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? (1)

sterno (16320) | more than 8 years ago | (#14743857)

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.

For most, yes, like a paper (1)

MikeRT (947531) | more than 8 years ago | (#14743999)

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.

CS Curricula (1)

sterno (16320) | more than 8 years ago | (#14744116)

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.

CS 101 (1)

sterno (16320) | more than 8 years ago | (#14744154)

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.

Re:CS Curricula (1)

ceoyoyo (59147) | more than 8 years ago | (#14744261)

Real CS should be learning things like bubblesort. What you want is software engineering, which DOES focus on design and reports and stuff. I find it all terminally boring, which is why I'm not a software engineer. Admittedly, the two were sort of confused for a long time.

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? (4, Insightful)

Vellmont (569020) | more than 8 years ago | (#14743980)


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.

What is an item about software development... (-1, Offtopic)

Anonymous Coward | more than 8 years ago | (#14743521)

doing on Slashdot?

I'm modding this whole darned topic off-topic.

He needs a new diagram at the end (2, Funny)

egarland (120202) | more than 8 years ago | (#14743538)

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.

Sorry to disappoint you... (1)

Spy der Mann (805235) | more than 8 years ago | (#14743603)

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.

Re:Sorry to disappoint you... (0)

Anonymous Coward | more than 8 years ago | (#14743800)

pft...

GIMP is a great (and useful!) tool.

I find the quality of usefulness of open source software to be top knotch.

Diagrams? Software Design by Evo Recap (0)

Anonymous Coward | more than 8 years ago | (#14743673)

A new diagram at the end? How about three dozen AI diagrams?

AI Algorithms Steps [sourceforge.net] are the latest in software design for open-source artificial intelligence (AI).

AI Theory of Mind [visitware.com] opens the doorway for programmers to cash in and launch life-long careers in the burgeoning field of artificial intelligence.

Diagrams of Artificial Intelligence [scn.org] teach the theory behind the design of artificially intelligent software.

Article text (diagram captions) (1)

Spy der Mann (805235) | more than 8 years ago | (#14743552)

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!

Huh. (5, Insightful)

Z0mb1eman (629653) | more than 8 years ago | (#14743593)

I read this blog entry with a growing sense of unease, until I got to this point:


The benefits of a product design process are well documented. New products that deliver superior, unique benefits to the customer have a commercial success rate of 98% compared to 18.4% for undifferentiated products. These products reach an outstanding 53.5% market share.


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. (1)

Spy der Mann (805235) | more than 8 years ago | (#14744004)

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

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. (1)

ceoyoyo (59147) | more than 8 years ago | (#14744301)

How about:

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. (2, Insightful)

hawkeesk8 (682864) | more than 8 years ago | (#14744007)

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." There is a real lack of "designers" in the software industry that are akin to physical product designers. Yes, you have to listen to customer's desires but if you ask developers to code to some spec that was solely created from customer "requirements" you will end up with shit software. You need a designer interjected into that process that has vision and can recognize where customers are feeling pain.

Re:Huh. (1)

kisrael (134664) | more than 8 years ago | (#14744182)

They way I've put it is "Customers don't know what they want 'til you build and show them what they don't."

Is it fair to say... (2, Interesting)

skoaldipper (752281) | more than 8 years ago | (#14743595)

...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).

Identifying user pain (5, Insightful)

c0d3h4x0r (604141) | more than 8 years ago | (#14743757)

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.

Re:Identifying user pain (1)

RatBastard (949) | more than 8 years ago | (#14744008)

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.

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 often you never know you've adjusted your gait until you go to the doctor.

I've worked on a number of small software projects and I never trust myself to make it as usable as posible without direct end-user feedback because I know that I have the habit of avoiding the less-than-perfect areas of the program. We all do it at some level.

Product "Designers" (4, Interesting)

wrook (134116) | more than 8 years ago | (#14743807)

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.

Re:Product "Designers" (2, Interesting)

AaronBrethorst (860210) | more than 8 years ago | (#14744095)

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.

Think inside your user (4, Insightful)

Opportunist (166417) | more than 8 years ago | (#14743856)

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.

Re:Think inside your user (1)

platos_beard (213740) | more than 8 years ago | (#14744111)

Please, please, please, do not confuse what makes your user happy with what sells.

Fluff sells. Usability (go figure) makes your users happy.

Re:Think inside your user (1)

Opportunist (166417) | more than 8 years ago | (#14744137)

Nope.

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 (1)

PitaBred (632671) | more than 8 years ago | (#14744262)

I don't like reading manuals, because it's sometimes really hard to find what I want. Gotta filter through a lot, and sometimes I'm not sure how to exactly describe what I want in terms that the help manual writer was using. What I have found is an invaluable thing, and something I wish I saw more of, is context-sensitive help. Getting a tooltip on a mouseover, or hitting F1 on a certain screen gets you help about what's going on in that one place.

HCI (4, Insightful)

kevin_conaway (585204) | more than 8 years ago | (#14743858)

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.

Where the problem is (2, Insightful)

Anonymous Coward | more than 8 years ago | (#14743934)

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?

Seeya in a Couple Years (2, Interesting)

Bob9113 (14996) | more than 8 years ago | (#14744078)

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.

Heheh, programmers get all the poo... (1)

maillemaker (924053) | more than 8 years ago | (#14744288)

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
Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account

Loading...