craftsmanship
-
I read a lot of articles and other commentaries that refer to software development as a combination of science, art, and craftsmanship. I think all 3 are absolutely part of producting software, and they can all differentiate bad, good, and great software. But in a lot of ways, it seems to come down to craftsmanship and pride. How much you do you really care that you truly understand the needs? How committed are you to meeting those needs properly without overdoing the solution? And will you be proud to claim that you produced the software once it is done and in use? Would you feel good about handing the support of that code to someone else without a bunch of disclaimers? If you don't feel like you can answer yes to those questions, odds are you won't have a successful piece of software...
-
I read a lot of articles and other commentaries that refer to software development as a combination of science, art, and craftsmanship. I think all 3 are absolutely part of producting software, and they can all differentiate bad, good, and great software. But in a lot of ways, it seems to come down to craftsmanship and pride. How much you do you really care that you truly understand the needs? How committed are you to meeting those needs properly without overdoing the solution? And will you be proud to claim that you produced the software once it is done and in use? Would you feel good about handing the support of that code to someone else without a bunch of disclaimers? If you don't feel like you can answer yes to those questions, odds are you won't have a successful piece of software...
In some way I blame this on software engineering being an immature business. Whenever our business has matured enough, I think there will be no room for players on the market that cannot deliver software with guarantees in the aspect of working software. Compare our business with buying a DVD player. There's always some kind of warranty connected to the product in the aspect of working as expected. If there wasn't such a warranty, would you buy the product? I know I wouldn't. Of course there are some disclaimers. There's usually a little note saying "warranty void if seal is broken". Everytime I speak to my boss about delivering software with warranty, he freaks out. I just feel that if you cannot deliver software with warranties, you shouldn't be in the business since you clearly don't know what you're doing. If you screw up, face the consequences and pay for it. Naturally there has to be some disclaimers similar to "void if seal is broken" preventing the customer abusing the product demanding that it should work in an environment it wasn't designed for in the first place. -- Roger
_It's supposed to be hard, otherwise anybody could do it!
Regarding CodeProject: "resistance is pointless; you will be assimilated"_
-
In some way I blame this on software engineering being an immature business. Whenever our business has matured enough, I think there will be no room for players on the market that cannot deliver software with guarantees in the aspect of working software. Compare our business with buying a DVD player. There's always some kind of warranty connected to the product in the aspect of working as expected. If there wasn't such a warranty, would you buy the product? I know I wouldn't. Of course there are some disclaimers. There's usually a little note saying "warranty void if seal is broken". Everytime I speak to my boss about delivering software with warranty, he freaks out. I just feel that if you cannot deliver software with warranties, you shouldn't be in the business since you clearly don't know what you're doing. If you screw up, face the consequences and pay for it. Naturally there has to be some disclaimers similar to "void if seal is broken" preventing the customer abusing the product demanding that it should work in an environment it wasn't designed for in the first place. -- Roger
_It's supposed to be hard, otherwise anybody could do it!
Regarding CodeProject: "resistance is pointless; you will be assimilated"_
Software EULA’s are already complex enough without having to detail all the things excluded in a warranty (Ours is over 5 pages of A4). The problem with warranties on software is that there are so many things beyond your control that can affect the way your product behaves. Would you for example want to warrant that the entire .NET framework is error free because a customer would neither understand nor care if the problem was caused by your code or Microsoft’s? Also every PC is different. Some may be identical in spec when they leave the manufacturer but as soon as they are used you end up having to deal with the complex interaction of many different items of software and hardware that can fubar your software in ways you could never imagine. Then there are other problems such as network problems etc. I understand what you are saying and I agree 100% that developers need to take some responsibility for what they write (which in many cases is one of the most important tools for the business) but I really don’t think a warranty is the best way to go. Only the naive would believe that the customer (or in some cases other IT professionals) wont hang you with that warranty over issues that you could not have possibly predicted. I would say the best way to go is in the support you provide. Help your customers in the best way you possibly can but make it known that it isn’t your responsibility (if it isn’t) and your help is just part of the service you provide. Jon
-
Software EULA’s are already complex enough without having to detail all the things excluded in a warranty (Ours is over 5 pages of A4). The problem with warranties on software is that there are so many things beyond your control that can affect the way your product behaves. Would you for example want to warrant that the entire .NET framework is error free because a customer would neither understand nor care if the problem was caused by your code or Microsoft’s? Also every PC is different. Some may be identical in spec when they leave the manufacturer but as soon as they are used you end up having to deal with the complex interaction of many different items of software and hardware that can fubar your software in ways you could never imagine. Then there are other problems such as network problems etc. I understand what you are saying and I agree 100% that developers need to take some responsibility for what they write (which in many cases is one of the most important tools for the business) but I really don’t think a warranty is the best way to go. Only the naive would believe that the customer (or in some cases other IT professionals) wont hang you with that warranty over issues that you could not have possibly predicted. I would say the best way to go is in the support you provide. Help your customers in the best way you possibly can but make it known that it isn’t your responsibility (if it isn’t) and your help is just part of the service you provide. Jon
jonathan15 wrote:
Software EULA's
Perhaps you may agree that EULA's are becomming so complex that they are fit only for lawyers to interpret. And end users are usually not lawyers, and these end users should be protected from unnecessary legal gobbledegook. I personally would like to see a reduction in the sheer quantity of conditions and clauses written in a manner that is both easy to read and easy to understand written in simple english. The more complex a EULA becomes it can be argued that the software that it refers to could be in some way "flaky" with exclusion clauses giving excuses why "it has fallen apart or just plain won't work as expected (or required)"
-
jonathan15 wrote:
Software EULA's
Perhaps you may agree that EULA's are becomming so complex that they are fit only for lawyers to interpret. And end users are usually not lawyers, and these end users should be protected from unnecessary legal gobbledegook. I personally would like to see a reduction in the sheer quantity of conditions and clauses written in a manner that is both easy to read and easy to understand written in simple english. The more complex a EULA becomes it can be argued that the software that it refers to could be in some way "flaky" with exclusion clauses giving excuses why "it has fallen apart or just plain won't work as expected (or required)"
All very true which is exactly why I don’t think a warranty on software would work. There are so many external variables that the developer has no control over that the clauses you would need to include simply to protect yourself from spurious claims ‘Under the warranty’ would make the EULA even more of a joke than it is now. jon
-
I read a lot of articles and other commentaries that refer to software development as a combination of science, art, and craftsmanship. I think all 3 are absolutely part of producting software, and they can all differentiate bad, good, and great software. But in a lot of ways, it seems to come down to craftsmanship and pride. How much you do you really care that you truly understand the needs? How committed are you to meeting those needs properly without overdoing the solution? And will you be proud to claim that you produced the software once it is done and in use? Would you feel good about handing the support of that code to someone else without a bunch of disclaimers? If you don't feel like you can answer yes to those questions, odds are you won't have a successful piece of software...
I can't answer "yes" to the first two questions as they are looking for an extent, manner or degree rather than a boolean ;-) '--8<------------------------ Ex Datis: Duncan Jones Merrion Computing Ltd
-
Software EULA’s are already complex enough without having to detail all the things excluded in a warranty (Ours is over 5 pages of A4). The problem with warranties on software is that there are so many things beyond your control that can affect the way your product behaves. Would you for example want to warrant that the entire .NET framework is error free because a customer would neither understand nor care if the problem was caused by your code or Microsoft’s? Also every PC is different. Some may be identical in spec when they leave the manufacturer but as soon as they are used you end up having to deal with the complex interaction of many different items of software and hardware that can fubar your software in ways you could never imagine. Then there are other problems such as network problems etc. I understand what you are saying and I agree 100% that developers need to take some responsibility for what they write (which in many cases is one of the most important tools for the business) but I really don’t think a warranty is the best way to go. Only the naive would believe that the customer (or in some cases other IT professionals) wont hang you with that warranty over issues that you could not have possibly predicted. I would say the best way to go is in the support you provide. Help your customers in the best way you possibly can but make it known that it isn’t your responsibility (if it isn’t) and your help is just part of the service you provide. Jon
Actually I wrote a longer reply during these hours half a minute a piece, but when I was about to send it the server complained and since I didn't copied what I wrote it's now gone forever. :mad: Basically my point is this:
jonathan15 wrote:
so many things beyond your control that can affect the way your product behaves
I'm aware of how things are for the time being, but this is what I refer to as immature.
jonathan15 wrote:
warrant that the entire .NET framework is error free
:laugh: Naah, I think not... This could be a good example of a disclaimer, unless I've endorsed the use of .NET to the customer; I should know better being an "expert". However, I feel that Microsoft is quite mature regarding this. When you buy a product from MS, say an operating system, you get updates or service packs for free to fix problems with the product you've purchased. This is what I meant by "facing the consequences". The opposite would be if MS would charge extra for the updates, but they're not and that's the kind of "guarantees" I'm talking about. I feel ashamed when a customer has to pay extra for software development he/she purchased just to make it work as expected. Of course this usually happens when the customer is charged by the hour, because it's easiest to make not too obvious for the customer. -- Roger
_It's supposed to be hard, otherwise anybody could do it!
Regarding CodeProject: "resistance is pointless; you will be assimilated"_