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 - Different Traits for Manufacturing vs Service?

Cliff posted more than 10 years ago | from the determining-what-works-best dept.

Software 23

tachin asks: "We've all been hearing about software as a service industry as opposed to manufacturing, there are some differences that favour that view, but I wonder if the type of industry affects the fundamental design of a software system. Considering the differences between those two types, are there some software constructs that are appropriate for one type of industry but would be undesirable for the other? As economies everywhere are becoming more service-oriented, what are the main characteristics a software system must provide to work well in such environments?"

cancel ×

23 comments

Time to market vs reproduction costs (3, Insightful)

Anonymous Coward | more than 10 years ago | (#8665710)

In order to serve customers well, you have to be able to quickly deliver a solution. The keywords in a service oriented software world are rapid prototyping and scripting. In a manufacturing oriented software world, hardware costs are more important, so you're going to see less cpu intesive programming styles. A prime example for manufacturing oriented software is the embedded market: Still lots of low level programming to keep code sizes down and speed high.

Tangible vs. Software (4, Insightful)

Graelin (309958) | more than 10 years ago | (#8665816)

You can blow all kinds of holes in these arguments by clearly defining what "tangible" really means. To say that because you cannot touch, smell or taste software it is intangible is incredibly flawed logic.

The code behind software can be printed. It is stored physically on a disk. These two things are good enough for the patent office and copyright law. They should be good enough arguments that software is indeed tangible. Another, somewhat easier, way to look at it is this: "Once you pay for it, it's yours forever."

You could also look at it this way:

If you are contracted to write a specific piece of software for a company you are performing the role of the manufacturer, and they are the customer. The price is variable, but once the project is complete the price becomes fixed. The company has a tangible product and does not need to contact you further. (Support contracts and the like really are separate products entirely, which most certainly qualify for the "service" mindset.)

Likewise, when a company employs an IT staff to maintain it's internal systems it really is a service role.

You can play all kinds of accounting tricks when you're supporting software. Does the cost of support add to the cost of the software? Not technically, the real cost comes from the hiring of support staff who likely service a wide range of internal systems. You can assign additional VALUE to the software though, since you have an established knowledge base with it.

The web complicates things a little. You subscribe to access to a web-based service. It is not tangible to YOU. It is tangible to the company you are subscribing to. These services fit both the manufacturing and service mindsets:

- The service provider contracted or hired the talent to build the software in the first place. This is manufacturing. Major upgrades and additions to the software are also manufacturing.

- The service provider contracts / hires the services of programmers to maintain their environment.

- The customer is purchasing a service from the provider.

I'm not sure if this even answers the questions asked. But it's 5:30am and it looks pretty good to me.

Re:Tangible vs. Software (4, Insightful)

martinde (137088) | more than 10 years ago | (#8666091)

> If you are contracted to write a specific piece of software for a company you are performing the role of the manufacturer, and they are the customer
> The price is variable, but once the project is complete the price becomes fixed.
>The company has a tangible product and does not need to contact you further.
> (Support contracts and the like really are separate products entirely, which most certainly qualify for the "service" mindset.)

I don't think the developer in your example sounds as much like a manufacturer but more like a plumber. "I installed the new pipes and checked everything out; it's now working. If something fails or your needs change call me and I'll come check it out and bill you hourly."

Plumbers perform a service despite producing tangible results. This is the model that I think that Open Source will lead to, if it gets enough penetration. As a developer, I don't know whether to be happy, sad, or indifferent, but it's what it looks like to me.

Currently software for the retail market looks like something different to me, but I wonder if it could survive if open source were to really start gaining acceptance? Could I take OpenOffice and put it in a box and sell it at Best Buy today? (source on the CD and so forth) Is there a market for that? What would my motivation be as a customer to spend even $10 on something I could get for free? Or what value could I add to something GPLed that is worth paying for by an end user? Support? Customization? More services are the only thing I can come up with easily.

Re:Tangible vs. Software (1)

mabhatter654 (561290) | more than 10 years ago | (#8674675)

I'd agree with comparing software to plumbing...it's very much the same. I've often thought the same thing that Software will become a Craft again rather than a "job".

To take your example one step further, programmers should be going after business, techinical or other skills that compliment their programming. The REAL power of programming is to provide the service of automating some task for the end user! The neat boundaries of OS developer, System Administrator, Programmer, User are quickly going away ... programming is moving to something that "just needs to be done" rather than some "ivory tower" task for gurus. I think OSS will help this because it moves the cost of the "toolbox" down to very cheap, meaning more people can get in the pool of developing solutions rather than simply paying money for "half useful" pre-fabed manufactured solutions.

Re:Tangible vs. Software (2, Informative)

mvdw (613057) | more than 10 years ago | (#8676142)

Could I take OpenOffice and put it in a box and sell it at Best Buy today?

The answer is a resounding "yes". The GPL not only does not forbid this, but this is one of the ways that a GPL-based company can make money. Read the FAQ on the GNU site.

If the question is, "Can I make money doing this?", then the answer is probably also yes, but with a few caveats. The main caveat is that people who buy software for themselves to use on a home level are few and far between - it's much easier to borrow a friend's (no doubt pirated) Office CD, than it is to pay money for Open Office.

Unfortunately until people realise that pirating software actually perpetuates the software monopoly, this mindset will continue. This mindset will probably still continue regardless of what people realise...

I use and advocate Linux, but I am not zealous about it. I am more zealous in advocating that people conform to whatever license is associated with whatever software they use, whether it be GPL, BSD or commercial software. Until people start complying with licenses, I don't think linux has much of a chance of gaining mindshare. Case in point: a colleague was showing us all an MP3 he had creating out of splicing some other MP3s together, just as a humourous thing. I asked him what he used, and he said he'd used a commercial software product, that he'd found a crack for and so he'd used that. I asked him why didn't he use Audacity, and he'd never heard of it. The problem here is that the free software doesn't get airplay in major computing mags, so Joe Average computer user doesn't know it exists, and goes for the commercial software he can get a crack for.

Tangible vs. Software-Tangy bits. (0)

Anonymous Coward | more than 10 years ago | (#8670839)

"You can blow all kinds of holes in these arguments by clearly defining what "tangible" really means. To say that because you cannot touch, smell or taste software it is intangible is incredibly flawed logic."

And yet such an argument is the basis for every P2P "pirate's" defense.

"Information Wants to Be Free" is a myth? (3, Interesting)

mandalayx (674042) | more than 10 years ago | (#8665869)

The original linked article is really long, so I read the next page. Luckily, it was shorter yet interesting.

The website claims that "Information Wants to be Free" is a myth:

The ``Information Wants to be Free'' Myth


There is another myth, equal and opposite to the factory-model delusion, which often confuses peoples' thinking about the economics of open-source software. It is that ``information wants to be free''. This usually unpacks to a claim that the zero marginal cost of reproducing digital information implies that its clearing price ought to be zero (or that a market full of duplicators will force it to zero).

Some kinds of information really do want to be free, in the weak sense that their value goes up as more people have access to them--a technical standards document is a good example. But the myth that all information wants to be free is readily exploded by considering the value of information that constitutes a privileged pointer to a rivalrous good--a treasure map, say, or a Swiss bank account number, or a claim on services such as a computer account password. Even though the claiming information can be duplicated at zero cost, the item being claimed cannot be. Hence, the non-zero marginal cost for the item can be inherited by the claiming information.

We mention this myth mainly to assert that it is almost unrelated to the economic-utility arguments for open source; as we'll see later, those would generally hold up well even under the assumption that software actually does have the (nonzero) value structure of a manufactured good. We therefore have no need to tackle the question of whether software `should' be free or not.


Interesting. I guess the point is that even if the cost of replicating code/software/information is very close to zero, the marginal utility can certainly be greater than zero. (high school economics, pull me through!)

Re:"Information Wants to Be Free" is a myth? (1, Interesting)

Anonymous Coward | more than 10 years ago | (#8666099)

It's a pity that English doesn't offer different words for the different meanings of "free". Information wants to be free (as in free speech), but not necessarily free (as in free beer). Lack of freedom in the former sense places a restriction on those who have the information, lack of freedom in the latter sense places a restriction on those who want the information.
"Information wants to be free" expresses the observed characteristics of information, mainly that it tends to diffuse into the open, even when there are active countermeasures to prevent leaks. It's a consequence of the fact that most of the time you have to duplicate/pass on information to use it. Material things do not have this tendency.

Re:"Information Wants to Be Free" is a myth? (1)

mabhatter654 (561290) | more than 10 years ago | (#8674597)

It's the difference between Knowlage and Wisdom. Information is simply Knowlage...any body can go to the library and get "knowlage"

Business is about Applying that Knowlage to your current situation. Your situation is always changing...it's a more like a living thing that has different needs all the time. Hence there will always be the need to employ people to find new knowlage and apply it to make you more money than the other guy!

Software fits this model because rarely is software simply "used". We don't still drive around in Model T's even though they are still great cars...our needs and wants have progressed past that level of auto...we also don't still use DOS because we demand more from software not because DOS is broken. That's a key difference!! Software is different because it's always in use..never finished. Business software is espically subject to this model because applying knowlage is key to business competition and software is a fundamental ingredient in capturing more knowlage and making better use of the knowlage you already got.

In reality software IS business nowdays. Proper use of software adds "wisdom" to your business so that you follow the knowlage and direction of the managers of the operation...it's a pain more MBAs aren't taught those priciples..

It really all depends (0)

Anonymous Coward | more than 10 years ago | (#8665978)

on how the answeree interprets your question. Personally, I've got no idea what you're trying to ask. Software is not standard manufactoring as such because nothing is physically produced. It is closer to a horoscope service than to a tinned food plant.

Re:It really all depends (1)

tachin (590622) | more than 10 years ago | (#8674174)

I did ask this "are there some software constructs that are appropriate for one type of industry but would be undesirable for the other?", for instance: if you want to hire somebody to work in a car assembly line you'd probably prefer a strong man over a cute young lady, and the opposite would be true if you wanted that person to talk to angry customers....so the question is: is there such a strong difference in chosing software systems depending on the type of bussiness?

Counterarguments to the article (4, Interesting)

G4from128k (686170) | more than 10 years ago | (#8666019)

The two top arguments in the article for why software is a service were erroneous.

1. 19/20 jobs are for in-house programmers This ratio may be true, but the conclusion that most software is written at the point of use as a service is false. If that one-in-20 commercial software company programmer writes commercial code that that sells even one thousand copies, then commercial code becomes 1000/(1000+19) = 98.1% of the code instances in use.

Another way to look at this is to examine the code inside the average company server for the ratio of in-house versus chimerical code. You will find maybe 10 million lines of code in a commercial OS, millions of lines of code in commercial enterprise applications (e.g., SAP, Oracle, Exchange Server, etc.), and a comparative fraction of that in code written in-house (config files, business rule scripts, report generators, PERL scripts, custom applications, etc.). Look inside the average desktop and the ratio of in-house to commercial code is even more extreme.

2. Remainder bin software: This argument is partially tautological. People (and retailers) devalue discontinued items or items from defunct makers because of the often valid perception that the item (or maker) was discontinued for good cause. If something did not sell on the shelves and the maker goes bankrupt, there is probably a reason. I will grant that future value plays a role in buying software, but part of the discount for remaindered goods reflects the low present use value.



Enterprise Does Have a Service Component: I think part of the difference lies in the distinction between enterprise software and consumer software. Clearly, enterprise software requires much more configuration, maintenance, and support -- its much more service oriented. The Accentures, EDSs, and IBMs of the world have made a ton of money on service related to software and IT.

Consumer Won't/Don't Pay for Service: In contrast, consumer software is much more manufacturing driven. There is simply no way that a $49 retail piece of software can come with any service. Nor, judging by the income statements of software makers, do these makers provide much service. There is simply no room in a $49 price point to cover the costs of real on-going tech support. Even upgrades are hardly a service -- the upgrade price is software half or 2-3rds the full retail price and given that the software maker gets to keep a bigger cut by selling upgrades direct, upgrades are a massive profitable product sales.

I doubt consumers will move to a subscription model for software (see Microsoft's attempts to do this) and I doubt they would like a pay-as-you-go model either. Most people bitch anytime that have to buy service (fixing a car, hiring a plumber, etc.) because most people place a less-than-salary value on their own time while the cost of service is always a more-than-salary amount (to cover benefits, employers taxes, support costs, profit, etc.) Do-it-yourself retailers like Home Depot and AutoZone have gotten very rich on consumer's asymmetric valuation of service labor. Consumers only want free service and that means bundling service into the retail price of a saleable manufactured asset.

Rising Ease-of-Use == Less Service:But I even wonder about the service model in all kinds of software. I would further argue that as ease-of-use improves, the need for service drops. The more a piece of software "just works" the more it acts like a manufactured good.

Even in configuration-heavy enterprise software systems, better interfaces could reduce the amount of coding-labor required to configure, maintain , and support big enterprise systems. The move from all-in-house applications to commercial enterprise apps also reflects a move to manufactured software. And as the enterprise apps accumulate functionality (SAP has 27 different inventory management algorithms), it becomes harder to justify paying in-house programmers to write one-off application. Now I'm sure that enterprise system will continue to need lots of service, but I wonder if the amount of service (per function point) won't decline as the systems become more plug-n-play, point-n-click.

Re:Counterarguments to the article (4, Insightful)

Spoing (152917) | more than 10 years ago | (#8668435)

I may not understand your point on the first one, though feel free to correct me.

#1 Summary of your point (?): On the one hand, if software made in-house is used by 1000 people that's 1000 users of that commercial code...yet on the other you say if your servers have software that represents the bulk of the source that source should count too.

Reply: The calculation for lines of code was never intended to be per-machine, it is "total lines of code written everywhere" = COTS_loc + remaining_loc. Oracle does not create a brand-new code tree for each and every machine it has licenced, yet spreadsheet macros and Access databases tend to be written on a regular basis, typically for well under 1,000 systems. (COTS ~ 'common off-the-shelf software'/sold as a product)

Having worked at both COTS software companies and on custom projects the difference between a product and a project is not trivial. The best contract software shops blend the two, though much custom code is still created and the volumes don't approach Word or even AOL cds let alone Oracle DB server. Moving an entirely in-house project to a product status almost always fails (with some noted exceptions).

The rest of your comments I either agree with in part or in whole.

"Ease of use" - One law I've learned:

  1. As software becomes 'smarter', the difficulty in using the software increases.

You can think of this as related to any complex system.

A hammer is simple, requires some training to use, has a limited set of problems, and skill with a hammer increases over time.

A nail gun is not simple, requires less training for the basics, has a variety of simple and complex problems, and experience matters quite a bit less over time.

That said, I'll take the problems with a nail gun over having to use a hammer almost every time.

Another example: At one of the COTS companies I worked for, our tech support questions on a utility program were almost always one of the same 5 questions. Time to answer each one was about 5 minutes.

The answers were obvious though the tweaking was difficult for a mere mortal. The thought was "if we automate the installation process so that it configures the utility automatically...people won't have to call us as much".

So, after a massive effort of automating the installation and configuration process, those 5 pesky 5 minute questions went away...to be replaced by 20-45 minute questions on a variety of issues we never realized existed.

The 'new' problems always existed, we just did not see them.

Re:Counterarguments to the article (2, Insightful)

G4from128k (686170) | more than 10 years ago | (#8669210)

Thanks for your thoughtful reply. I suspect we agree, we only differ in how we measure "amount of software."

Consider an example. Assume that each company has 1 programmer and a 1000 employees, and there are 1000 companies, and each company programmer writes 50,000 lines of code. Then you have 50 million lines of written code scattered across the companies, and 50,000*1,000*1,000 = 50 billion person-code-lines of usage of those custom code lines. On the other hand, if SAP hires a 1,000 programmers, and each writes 50,000 lines (50 million lines in a massive application) and then SAP sells the application to 1000 companies with 1000 employees each, then we have 50,000,000*1000*1000 = 50 trillion person-code-lines of usage of those manufactured lines of code. In this example, we have a total of 2,000 programmers and a total of 100 million lines of code but the average employee is using only 50,000 lines of custom created code and 50,000,000 lines of manufactured code.

I'm only pointing out that most of the software used by any given person (it terms of lines of code) is manufactured software. In fact my understanding of why companies like SAP and Oracle are so successful is that its more cost effective to use manufactured software (with configuration) than it is to custom-create everything -- why reinvent the wheel.

In the manufacturing analogy, software engineers are like the engineers at a manufacturer -- they design once and the company replicates many. Big software companies attempt to invent the wheel once and then sell it many times -- a manufacturing model that seems increasingly popular. Yes, there is a service component to software (similarly there is a service component to manufactured goods in many B2B situations)

"Ease of use" - One law I've learned:

As software becomes 'smarter', the difficulty in using the software increases.


That is a very important and confounding point! The people that rail against the complexity of some categories of software (especially enterprise systems) have no appreciation for the complexity of the functionality required by these systems. Many applications are hard to use, in part, becuase the domain is hard.

My point is that bad design makes applications even harder to use and thus requires more support, maintenance etc.

Now that you mention this issue, it suggests another trend in software support. As the software becomes easier to use there is less need for technical support. But, as you correctly point out, the software tends to become more functional and complex in the domain. Thus, I suspect that helpdesk people will need to switch from being software experts (that solve IT problems) and becoming subject matter experts (that help users solve business problems).

So, after a massive effort of automating the installation and configuration process, those 5 pesky 5 minute questions went away...to be replaced by 20-45 minute questions on a variety of issues we never realized existed.

That's a funny story and very true, too. The question is: did total support labor drop and did total adoption and use increase? I'd wager that after that application became easy to install, more people used it and that support per user-hour-of-use actually dropped.

Re:Counterarguments to the article (2, Insightful)

Spoing (152917) | more than 10 years ago | (#8670251)

  1. I'm only pointing out that most of the software used by any given person (it terms of lines of code) is manufactured software. In fact my understanding of why companies like SAP and Oracle are so successful is that its more cost effective to use manufactured software (with configuration) than it is to custom-create everything -- why reinvent the wheel.

    (calculations using SAP as an example)

Come to think of it, this is even more effective when it's OSS; why reinvent the wheel when a perfectly good car is parked there ready to use...or to slap a coat of paint on. Spare engines, gas, and tools are also there -- and you are encouraged to take them.

As for the calculation of code use, I'd stop at lines generated and not put in the user multiplier. The extra work per-user is minor (see below) and explains why some software companies can't make a dime while others have Scrooge Mc Duck-sized money vaults filling up on a daily basis.

Also, I doubt that SAP (or any product for a vertical market) gets that many users per-product. It's also not the bulk of the software installed. The bulk of the code in use is in the form of the OS (if we count per-machine), common 'office' client applications, or a web server and supporting extentions/databases (counting per-user times a variety of web apps and web servers/server farms).

  1. My point is that bad design makes applications even harder to use and thus requires more support, maintenance etc.

From experience the harder software is to use, more people are blocked from using it...thus less support is needed. Make it easy, and support costs will increase. There could be sweet spots in that mix, and for some products this will not be true, though I can't remember many (I worked on ~10 COTS programs, 3 sucessful and of that group one was very very sucessful).

  1. That's a funny story and very true, too. The question is: did total support labor drop and did total adoption and use increase? I'd wager that after that application became easy to install, more people used it and that support per user-hour-of-use actually dropped.

Sales increased (more people could use the tool), support costs increased (more people who shouldn't use tool did -- plus experts had harder more detailed questions), development costs went up (more code to maintain and new demands and requests were placed on the software). All in all, the only thing that went down was the developer-time-per-customer; we went from a staff of 3 programmers to 5 but the sales went up 10-30x (after a while the owners stopped telling us how well things were going).

Making Money Off Services (2, Interesting)

DaRat (678130) | more than 10 years ago | (#8666242)

One of the dangers of buying software as a service is that the vendor company may be tempted to forgo quality or ease of installation/changes if the contract specifies that installation, changes, or bug fix services are conducted under a time and materials contract. In that case, the service company has an incentive to provide as much "service" as possible since that means more money.

I once worked for a consulting company that was a partner to compensation software company. I got this feeling that the compensation software company didn't feel the need to make their products easy to implement or of high quality (bug wise) because all contracts were essentially time and materials contracts. Thus, the harder the packages were to implement, the more money that the software company (and my employer) made. Thankfully, I only stayed with the consulting company for 9 months before moving on.

Re:Making Money Off Services (2, Interesting)

Rick the Red (307103) | more than 10 years ago | (#8669557)

Even if what you say is not true (if the company produces the best software they can, with no attempt to make it bad just so you'll pay for more service down the road), there's a danger here. I call it the Ma Bell syndrome. Ma Bell used to own all the telephones; in fact, it was illegal in some areas for the customer to own their equipment, the theory being that if their equipment damaged the network then public safety could be affected -- only The Phone Company's equipment was known-good.

Software is similar in that the customer does not own the product they bought, they simply own a license to use that product. To me, that makes software more like the old telephone system. It's clearly not like a manufacturing industry, but it's not really a service industry if there's no service. Softwear is not either/or. It can be a service industry (virus scaners where you subscribe to the updates) or manufacturing (open software where you're free to do with it what you like). It's really up to the author (copyright holder) to decide what business model to follow.

If software was like manufacturing, then once you bought the software you would own it and be free to do whatever you wanted with it. As it is now, if you buy Windows with a Dell computer, you not only may only run that copy of Windows on a Dell, you may only run it on that particular Dell -- talk about not free to do what you want with it! If you load Linux on that Dell you cannot legally use the Windows that came with it on any other computer; to do so violates copyright law. And I'm not picking on Microsoft, either. My wife and I bought otherwise identical Dells, but we bought them a few months apart. They came with different bundled softwear (different picture viewing softwear, for example), and we cannot swap them unless we swap computers. Think of all the "free" softwear out there, such as Real, that you cannot give to a friend even though you got it for free. Your friends have to download it themselves. This is not a manufacturing model of softwear, even if it's also not a service model.

I think if more people understood this they'd be more inclined to support Open and Free software.

Some Off the Wall Answers (2, Insightful)

4of12 (97621) | more than 10 years ago | (#8666266)


As economies everywhere are becoming more service-oriented, what are the main characteristics a software system must provide to work well in such environments?"
  1. Low monetary cost of purchase and human cost of deployment.
  2. Low monetary and human cost to maintain.
  3. Easily adapted to suit changing business needs, including moving between different hardware and software systems.
From what I've seen, current software offerings only partially fulfill this laundry list.

Which means there's room for improved products.

Once the purchasing costs are pushed down low enough, what matters most is that service-industry employees are made more productive by using the software; i.e., human factors.

And, if your software can make cheaper human beings function more like expensive human beings, then that's a plus. [Throw the rotten vegetables at me, but recognize it's because passing off cheaper workers for more expensive workders been done so poorly, so frequently, and, face it, can never be done completely.]

Re:Some Off the Wall Answers (1)

tachin (590622) | more than 10 years ago | (#8674091)

I like that "expensive human being" argument, probably most of the time that human being is the same, cheaper if she does some stupid task, more expensive if she can take care of a customer phone call since some technological device is taking care of the stupid tasks. Thus, the software for service oriented bussinesses should add value to the workers? That would explain the importance of good GUIs for instance..

Programming, the new ketchup! (0)

Anonymous Coward | more than 10 years ago | (#8667294)


Hey, if burger [gamersnook.com] flipping [cbsnews.com] can be [volanteonline.com] manufacturing [johnmccrory.com] , why can programming?

Steal this program! (0)

Anonymous Coward | more than 10 years ago | (#8667322)


If copyright violation can be considered theft [m-w.com] of intellectual property [m-w.com] , then I suppose the creation of that property could be considered manufacturing [m-w.com] .

It's only "service-like" if it's lousy... (2, Insightful)

dpbsmith (263124) | more than 10 years ago | (#8668834)

In the early part of the century, automobiles were big, technically complex, unreliable, and needed expertise to run and maintain them. To put it simply, if you wanted to use an automobile, either you needed to be a technically sophisticated hobbyist or you needed the services of a chauffeur and a mechanic.

Now, they're product-like.

Software should be product-like. It is service-like because a) we still haven't figured out how to do it, and b) there is a combination of interests that is well-served by the status quo.

Remember Fred Brooks (3, Insightful)

Brandybuck (704397) | more than 10 years ago | (#8674696)

Fred Brooks made a lot of insightful observations about software. But they can all be boiled down into one: "Software is unlike anything else in our experience, so don't treat it like it is." (that wasn't his observation, that's my high level executive summary). If you treat software like manufacturing you'll get it wrong. If you treat it like service you'll get it wrong. If you treat it like anything else in the world, you'll get it wrong.

The next time someone says "we have to treat software like [anything other than software]", rest assured that they're wrong. But or course, your boss is paying attention to them, so you might as well learn the new buzzwords for the month...
Check for New 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...