Software - Different Traits for Manufacturing vs Service? 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?"
Time to market vs reproduction costs (Score:3, Insightful)
Tangible vs. Software (Score:5, Insightful)
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 (Score:5, Insightful)
> 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.
Some Off the Wall Answers (Score:3, Insightful)
As economies everywhere are becoming more service-oriented, what are the main characteristics a software system must provide to work well in such environments?"
- Low monetary cost of purchase and human cost of deployment.
- Low monetary and human cost to maintain.
- 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:Counterarguments to the article (Score:5, Insightful)
#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:
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.
It's only "service-like" if it's lousy... (Score:3, Insightful)
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.
Re:Counterarguments to the article (Score:3, Insightful)
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 (Score:3, Insightful)
(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).
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).
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).
Remember Fred Brooks (Score:4, Insightful)
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...