The Problem With How Software is Developed Today
So, Terry White and I on the phone talking about yesterday’s post, and more specifically about how software is really developed today—all software, whether it comes from Apple or Microsoft or whomever. Terry had the perfect analogy to describe how it is from our, the end users, perspective:
So you’ve been waiting for this new restaurant to open for 12 to 18 months, and when it finally opens you head right down there. They seat you and hand you a menu with all these great dishes on it, but after a few minutes, they come and take the menu out of your hands and set down your food.
You ask the waiter, “What’s this?” He says, “This is your dinner.” And you say, “But I didn’t order this,” and he says “We decided this is what you want.” So, you go ahead and taste the dinner, and some things taste pretty good, and others you don’t care for, but you eat it anyway.
Then you ask the waiter, “Why is my fork way over there?” He says, “We decided to move it because we thought it would be easier for you to use over there.” So you say, “Why didn’t you just ask me where I wanted the fork?” [Blank stare].
When the waiter comes back by again, you ask, “Can I order some of the things I want off the menu?” and he says, “Maybe when you come back next year.”
It doesn’t have to be like this, because the software industry has the power to change the way software is designed. They just have to want to change.
this sounds like my brother-in-law complaining there’s no good music - no really good bands coming out anymore.. and the only thing i can say is yes - if you’re doing nothing but passively consuming what is coming out of the radio - listening to what the *industry* thinks is good for you, you won’t find anything “good” or “new” anymore.. u have to go out find it yourself.. the variety has vastly grown compared to times when there was not much besides beatles or stones, so many can (and) do music today, u gotta find the pearls yourself..
but if one’s blinded (or payed) by the big ones, of course it’s hard to get out of the “mainstream”..
my2c.
As a software developer, I see this differently. When you say “Why didn’t you ask me where I wanted the fork” you may get an answer of “well, the last guy who was in here loved where his fork was”. You, being Scott Kelby might get your fork moved, but me, being Not Scott Kelby, wont.
You can also say “Well, I want an OPTION to put the fork where I want it”. That’s true too, but at some point, you have to decide what you’re cooking, and cook it. Too many options, and people will say “I’m tired of you asking me questions, where’s my food? This is complicated. I just want to eat. Where’s my beer? How many calories are in this?”.
Software designed by committee is much like a movie script (or anything else) designed by committee. Usually not so good. Plus, many on the committee don’t really understand enough about the underlying structure to design useful functions in many cases.
Go over to the Lightroom Beta forums and you’ll see perfect examples of requests from users that seem at first to be good ideas until you see that they make little sense. Users want Lab curves in LR. Well if you understand the underlying color processing in LR or ACR, you will understand its not necessary nor possible. Then you ask “what is currently a problem with the curves that make you feel you need Lab curves?” No answer. They just “want” the feature but don’t know if its needed or possible. Same with users who want to build ICC camera profiles for Lightroom because you can do this in other Raw converters. Well LR and ACR are unique in how they use two proprietary non ICC profiles to give you rendering controls like Tint and Temp (and the Calibrate tab). But they WANT to build and use ICC profiles. Sorry, isn’t going to happen. A really smart guy by the name of Thomas Knoll came up with a better mousetrap. But users all over the web ask for these “features”.
Having worked with the Adobe team as a beta and alpha tester (since PS 2.5), you CAN get features you desire but you have to prove the points by using sound empirical requests to back up why a current tool or function isn’t cutting it. A want alone isn’t going to convince this smart team that they should even consider the request unless its got some beef. Some users have good ideas and can back them up, others don’t. And Adobe has had a mechanism for users to post feature request for years. The Adobe team DOES look at them. You just need to make a very sound case, with good data points as to why. Saying something like “well so-and-so’s software does this” isn’t enough.
As Jeff Schewe, a fellow alpha tester has written, “be careful what you ask for, you might get it!”
Wouldn’t the analogy be more accurate by saying the menu is missing an item or two that you’d really like to eat, so you ask the waiter if you can order something that’s not on the menu? i.e. Is not the menu their decision of “what you want”, from which you can pick for yourself what you eat and what you ignore?
I guess Bill, above, stated very well my perspective on it, but then again, I’m also coming from a computer science/software development perspective. . .
The restaurant analogy just doesn’t work when it comes to software development. There is no menu - there is a single product being developed. And it is being developed for lots of potential customers, not just the one who comes in and sits at the table.
Finally, there are lots of features that customers want and need, but don’t know it or don’t care to think about. The restaurant customer probably needs an exhaust vent over the grill back in the kitchen, but would never think to ask about it.
It’s the restaurant owner’s responsibility to meld all of the explicit requirements of all of his/her potential customers and all of the implicit requirements into a single final product. Add to that the restaurant owner’s expertise in running restaurants - a necessary skill that the customers don’t have or need.
Creating a final product that appeals to all of the potential customers and best (not perfectly) meets their needs is much more than taking orders off of a menu.
We get that in small plane aviation, too, where computer screens and buttons have replaced traditional round dials. There are little tiny buttons that your finger can’t target when your arm is bouncing in turbulence. It worked fine for the software engineer, sitting at his non-moving desk. And there are several ways to do the same task, increasing the workload.
When you enter your radar code, would you like to just push the knob to turn on the cursor, and then turn it to change the code?
Yes, that’d be great. Thanks.
How about having the alternative of plastering numbers across the bottom of the screen with a button for each number, and up the side since there isn’t room for numbers one to ten along the bottom?”
No, that isn’t necessary. First method works fine. Don’t make it more complicated than it already is.
Ok! Here are both methods for you. Your systems costs a little more now. Sorry about that. But you have TWO ways to don one thing! Great, huh?
As a QA Engineer at Adobe having worked on the release of several web technology products, I have to say that Andrew Rodney’s comment above hit the nail on the head, precisely, and I second it entirely.
Software Development is to complex now-a-days! I’ve been in this business too long!!! There’s no right or wrong anymore…just a project deadline that is impossible to meet.
…where’s my camera? I need to shoot something! I mean “photograph” something!…
That hits way to close to home! As a Web Designer, this is exactly what I deal with. Why is the fork there? Because a manager wanted it there, the client thought that it would work there, and you - the customer - need it somewhere else. And sometimes you only get the salad because the dinner is still cooking. And if dinner is burnt - deal with it.
Agh, this is so good!!!!! I also work with Section 508 - throw that into the mix and EVERYTHING changes. Too funny.
I can certainly understand and sympathize with the comments here from the user perspective. However, as a software developer I have to say that the restaurant analogy just doesn’t work. There is no way you can compare getting a meal in a restaurant with getting an upgrade to any software, let alone something as rich and complex as Lightroom or Photoshop.
A better analogy might be to compare your software wish list to your wish list for a new automobile. The time and effort to produce software is much more comparable to that of producing a car than it is to producing a meal.
So you think you need a new car. You can drive around to the 1/2 dozen or so car dealers in your area and see what they have on their lot and pick one that best suits your needs. It probably won’t have everything you want, but you make tradeoffs to find the one that is the best value for the money you want to spend. This is like walking in to your software store and buying something off the shelf.
If nothing comes close enough, you can visit your favorite dealer and go through the list of available features picking from those that already exist and order your car from the factory. Doing so will take a few weeks, maybe a few months, but you can get something a lot closer to what you want. This might be like Scott’s request to have LR before/after in PS. The feature already exists, and one would hope that the software components Adobe uses to display images in the two products are similar enough that it would be a fairly small matter to just port the feature from one to the other (although I’ve seem many times when something that appears this trivial has unseen complications)
But suppose you want something completely new. You want Corvette, but you want it with a FlexFuel motor. Or you want the economical Chevy Cobalt but you want it the luxury entertainment package - rear seat DVD with a Bose sound system. Things that aren’t even on the menu. Those things are probably doable but for that to happen enough people have to ask for it, which takes time to establish a critical mass. Then the decision makers at Chevrolet have to decide they will do it, another chunk of time. Then the engineers have to design it, still more time. Then it has to be built, and presumably you as a customer want it to be safe and work right so it has to be tested. And at some point - on the order of years for a car, but even several months in the very best case for software - you and others like you can get the new features in your car or software.
Photoshop and Lightroom are phenomenal products. And in skilled hands nearly any image manipulation you can dream of can be done with those tools. But we don’t have, and may never have, that level of ease, flexibility and speed in tools used to design, create and build cars or software.
Damn straight, Scott. Too often “upgrades” are inflicted on the customer base. To my mind, Microsoft is the worst offender.
You know scott, this is so true. As a software engineer myself I can tell you how many times I see software design choices dictated not by user requirements, but rather by the developer’s daily jolt of creativity. Now, I’m not saying people at Adobe work like this though.
Scott,
This argument certainly has two sides. I’m not sure I see a simple solution in the short term. But that’s great news for you and me (Photoshop authors and trainers). The issues with the fork being too far away and some of the side items not being too tasty are exactly why Photoshop books and training are so popular. I’d love to see this issue resolved. If that happens I’m going to be following your lead for my next career.
I want software to have all their cool features packaged in a way the “average†user finds most useful, but I’m with you Scott: I don’t want choices and options made/selected for me, especially when this is seldom done well in this age when almost everything is dumbed down to the lowest common denominator.
Cheers,
Russ
As a retired manager of software testers and developers, my view is the first thing that should be written is the instruction manual. Then write the software to fit. There are so many things that LR can do that are not called out, that it is not surprising people ask the wrong questions or say “I didn’t know it could do that.” Also better indexes of the instruction manual would help. Most developers know what it can do so inadvertently feel that it should be obvious. Usually it isn’t. If that were done, there would be little need for the s/w book writers though, and that would make Scott unhappy. LOL
Mel
Scott,
I think your analogy is really clear and also entertaining (as is your talent). However there is one problem. When you go to a restaurant, you can’t just sit down and say “I want a buffalo steak with Japanese mayonnaise on top” when they don’t serve that dish. You’re still expected to stay within the boundaries of the restaurant’s culinary vision for how food should taste. You might want your steak a little more rare, or to substitute broccoli for potato au gratin, but you can’t just go nuts and order anything you can think of. Because no restaurant can “stock” and “specialize” in all of those things. Likewise, how can a developer expect to meet any need that can be dreamed up for the next release, especially if it starts to head in a direction that overlaps other products or does not meet the original functionality goals?
This is how it usually works:
http://www.planetb.ca/uploaded_images/Project_LifeCycle_Swing_Analogy-760487.jpg
And the most sad part is that it is true.
I was going to jump in with a comment from a software developers perspective but it seems a few already beat me to it. Some very good points in their comments.
While user interface is a very important aspect to any program, I would still choose certain features above it. For example, if Adobe said I could either get the Camera RAW update as seen in CS3 or all the filter menus looking like the Smart Sharpen UI…. I would choose the RAW upgrade. I am not implying that you or anyone else would but just stating that there are trade offs to be made and so far I think Adobe has been doing pretty good job at making the right choices.
Nice analogy, and so true. Gavin
Why is it that Photoshop User TV never tells me exactly what I need to know the next week? Its always whatever the hosts decide, why is that?
The photoshop training industry needs to change so they can deliver exactly the training I want
As has been stated, the analogy just doesn’t work because this isn’t a menu where each patron can order separately. This is one dish that has to satisfy everyone who came to the restaurant. This is a popular restaurant too, frequented by a growing and more diverse group. You have engineers, video producers, web designers, photographers, digital painters, beginners, advanced users… Every one of these groups has their own way of using Photoshop and their own ideas of what would take it to the next level. Many of those ideas will contradict each other. Supporting such an eclectic group is the problem that comes with bringing such a powerful and popular tool to the table.
From my experience in the software industry, one of the major hurdles with development is that creativity is stifled by the product life-cycle and marketability. You have the guys that know the product inside and out and have a good idea of where they would like to take it to push it to that next level, then you have the company as a whole involving the marketing and research department that are asking questions like “What is the most profitable sweet spot for a product life-cycle?” or “What new feature has that zing to it that will make the most people drool?”. The answer that first question can often hinder the creativity of the product engineers because they are given pretty extreme deadlines that automatically derail a lot of their ideas. The answer to the second question begins an even more vicious cycle: new features are more marketable to Joe Public than fixing or fleshing out old ones->trying to compromise on time spent developing between new feature and fixing old ones->”tacked on” new features, little improvement to old ones->More features that will need to be fleshed out after release while competing with whatever needs to be tacked on to add “zing” to the next release. Many companies are in a vicious cycle with branded titles because that sweet spot for profitable profit life cycle is 1 to 1 1/2 years.
Photoshop actually gets the big dev team because that’s the flagship of Adobe. Consider many of their other titles that get pretty minimalist upgrades between versions because their dev teams are much smaller. I’m not just saying this life-cycle is applicable to Adobe only. In fact, I would say that they are one of the better companies at handling it. I’m just trying to give a glimpse of the pain that most developers go through from a distant view of the company as a whole.
It has been stated in these comments that Adobe’s shortcomings are what keep you in business, but I would think that is a bit of a cynical view. Their shortcomings helped to drive a need for a lot of what is going on at Photoshopuser, but what is here has grown and thrived beyond the satisfying of that need thanks to your vision and hard work.
I work as a developer for a big financial software company and I use LR. Dealing with users is not easy, especially when there are millions of them. We have to develop software for the masses, i.e., satisfy the vast majority of them because they have common requirements and needs. Then we develop to solve the problems for the rest of them… when we have time. We conduct a lot of usability lab sessions with actual customers to find out what they want, and the way they react in front of the software we give them (beta versions). We sit down in our darkrooms, behind our one way mirrors, eating m&ms while the customer is trying to execute their every day tasks in our software. We film them, record what they say, record their eyes movements and correlate that to the item they look on their screen. This is extremely useful for us because the way developers think is different from the way users think (the plane analogy with tiny buttons and screens instead of knobs is accurate). It sounds like Adobe listens to their customers. Hopefully some day, there will be in LR or Bridge the features we (i.e., the vast majority of us) want. Hopefully, they will fix the bugs too and correct some inconsistencies between the 2 softwares.
Well I personally think Adobe is doing just fine and should hold out longer than 18 months for a new release. I just upgraded to CS3 about a month and a half ago. I waited because I wanted to make sure there weren’t any bugs like Apple did with Leopard or Canon did with the Mark III. Now I feel like I really didn’t need the upgrade because I hardly use any of the new features and I mostly work out of Lightroom unless I want a certain look. I do, however like the new upgrades with Lightroom 2.0 beta. I think if they waited every 2 or 2/12 years with an upgrade they would have more time to get more features in and the release would seem worth the upgrade. I definitely wouldn’t trade my car in every 18 months. Just my opinion
There are many issues regarding software development. I’m a senior software developer for a top 10 financial company in our field. I can tell you that politics plays a large roll in what gets developed. The politics can be from internal people who have to push their pet projects through or politics with a big customer who demands a certain feature even if it breaks what the majority needs.
Theoretically, Agile software development can deal with this but the logistics of producing a product that will be used by millions is very difficult. Most companies refuse to spend the time or money in extensive user testing and proper UX planning. And realize that all development comes with the idea that some bugs are more “acceptable” and can be released anyway. It has to do with the cost/benefit ratio of the features being released.
There are no easy solutions but from this developer’s perspective I think one thing would help: attention to quality. The ideal of craftsmanship has eroded over the decades to being non-existent. I would like to see a revival in caring about what we work on and wanting it to be the best.
So - here’s the deal - I loved the analogy, truly made me laugh.
I am not surprised that some software developers are pissed about this, and the “Scott Kelby” example doesn’t fly with me. Don’t get me wrong, I wouldn’t be half the photographer I am without Scott - but industry can’t use the guru response. Here’s what I mean…. there are relatively few people in the guru category that developers can gear changes to.
However, all being said, gurus like Mr. Kelby are the expertise that we all draw from.
So….all aaid - software developers tale note- release a Beta - give lots of opportunities for feedback and develop some metrics to gain the knowledge of the masses…………..
and listen to the Masters like Scott , but also listen to those who Scott gives the greatest advice to!
Lots of good comments above. I’m in the camp that thinks Adobe is doing a pretty darn good job with their products already. I mean, they are the biggest company in their field and yet most people still really like their products (unlike Microsoft) and have given us many tools over the years most people wouldn’t even think of, but now can’t live without. I think they already involve the consumer quite a bit with their beta programs.
Scott, this is a bit off topic, but I know you actively read your blog comments and figured this is a good place to ask. I was trying tom come up with a photoshop action that would add a mat to an image and leave double the room at the bottom for a name plate. I’d like to have something that works for an image regardless of aspect ratio, but I’ve been unable to do that so far. An square image makes it easy, but a 4:3 is much trickier. Is there a way to do this with 1 action? Or am I going to have to have several actions, one for each aspect ratio. Cheers!
I work for a major software company and odds are you are using at least one of our products. I can tell you that we build our products entirely based on customer feedback, but the problem is that when you have 500,000+ customers, you can’t take every suggestion and wish and make it a reality. Shipping is a feature too, so you have to take the ones that are requested most frequently and evaluate the cost/benefit of those features and decide which can be implemented in a reasonable time with the available resources at hand. Any company that doesn’t build software based on user input simply doesn’t survive in this industry for very long, but the problem will always remain that what is a great feature for one person will be a pain in the a$$ for another. If you cater to the beginner you make the power user unhappy, and vice versa. So what do you do? You try to strike a balance and go back to the “most bang for the buck” way of choosing your features for the next version.
While people like to complain and say that companies like mine don’t listen, the fact is that I’ve seen repeated instances where one customers gripe/suggestion take priority over all of the developers and program managers input. As a consumer, at least with my company for the nearly 14 years I’ve been there, this is how it works. I don’t believe Adobe follows this policy to the same extent we do, but they have to be doing a little bit of listening to their customers otherwise they couldn’t continue to create compelling new releases that cause people to pay the huge upgrade fees they charge.
Heck of a topic…heck of a thread…My studio opens in a week…stop by sometime…you helped get me going…thanks my friend
The Blurry One
I’ve worked in the software industry for many years, and here are some home truths.
1. All commercial software is created by programmers who almost never use the software. They don’t care what dishes are on the menu and they don’t care where the fork is. They do what they’re told and they build the restaurant the way they’re told to build it. If those instructions result in a confusing restaurant, that’s not their problem. Hell, if they’re in a big company they might not even KNOW they’re working on part of a restaurant.
2. The instructions are given to the programmers are inevitably driven by the marketing department. Newsflash, the people in marketing don’t use the software either. Not only do they not use the software, they don’t understand the technology. All they know is “what’s hot right now”.
Most commercial software is created based on the instructions of ignorant people passed on to indifferent people. That’s why most of it is crap.
I like this analogy.
It would be even closer to the truth if the waiter snatched the menu out of my hands when tried to order and said “Aha, your accent tells me that you’re not from around here. You have to order from the specials menu. It’s exactly the same as the menu you were just looking at and comes from the same kitchen but it’s twice the price!”.
I don’t like the idea of Adobe asking ALL their customer what they want. The signal-to-noise ratio would make this useless.
The best example of software development is Robert McNeel and Associates Rhino (www.rhino3d.com). They pioneered completely open development and had Rhino in beta for 7 years before they released it. They hosted a forum where users would support one another. Users would download new versions of Rhino that ran for 90 days. Every 90 days you’d simply download another version. The development team would watch the conversations that took place and steer the platform development to support the needs of the users. And they rewrote the app from scratch more than once.
I believe/hope that Adobe is using the lessons of McNeel in developing LightRoom. I don’t want a product designed by committee, like the Pontiac Aztec. I want a product designed by someone with a vision, like Enzo Ferrari did. Ferrari created the car HE wanted, with input by people he respected (F1 drivers).