Software Engineering blog » Week 3 http://softwareengineeringblog.com Software - Art Fri, 03 Feb 2012 14:43:00 +0000 en hourly 1 http://wordpress.org/?v=3.3.1 Liability or reality? http://softwareengineeringblog.com/http:/softwareengineeringblog.com/software_engineering/liability-or-reality/52 http://softwareengineeringblog.com/http:/softwareengineeringblog.com/software_engineering/liability-or-reality/52#comments Sun, 29 Nov 2009 06:57:44 +0000 Laszlo http://softwareengineeringblog.com/?p=52 I chose this question one because of my personal experience. My company made a website for a client who was our partner for many years. It was more than a partnership, near to a friendship. We were near to the end of the project (two days before the handover) when one of our partner’s employees made an error, our partner thought that we made it and because his life in those times was very stressful he got mad.  He decided to sue us to pay back all his money and refused to pay our remaining fee. It’s a four year old story and we’re still fighting on the court. I not just can imagine, but I know exactly how difficult is to define the limits of liability.
Theoretically it is possible to make error free programs. Francez Nissim(1993) thinks that using discrete maths and formal logic it is possible to make error free algorithms. But programs are the implementation of the algorithms. Programs are made by engineers and not mathematicans. Nowadays applications are running on the top of many layers, eg.  operating system, code frameworks, they are using device drivers to handle hardware devices. For software development we use editors, compilers, IDEs. All mentioned layers and tools are programs themselves, too and they are made by a lot of programmers. Sometimes hundreds of programmers are working on one of those programs. We know, the man is not perfect. Practically even if our software is perfect, it has to run on thoose layers and it has to be made by the mentioned tools. Since any of them can contain errors what affects our software, we cannot guarantee that our software will work perfectly.
On the other side, software is a key factor in our life now. We can find them even in some washing machines or refrigerators. Charlie White (2006) wrote about an existing  smart refrigerator in 2006, years ago! Softwares participate in flight control and airplane driving. They do almost all calculations instead of engineers who build skyscrapers or malls. It’s obvious for me, that developers need to be responsible for their work. The ethical liability is obvious. The hard part is the legal liability. Glyn Moody (2009) writes about several possible solutions. EU proposes a regulation, what says that software should work perfectly in normal conditions. They say it’s the customers’ right – which sounds right. He cites Bruce Schneider, who wrote: “Computers are the only mass-market consumer item that pushes this burden onto the consumer, requiring him to have a high level of technical sophistication just to survive.” What makes this question even more difficult is Open Source software. Who can find the guilty amongst hundreds of contributors, who many times just use nicknames to sign the code?


Reference list:
Charlie White (2006) Samsung Smart Zipel Refrigerator [Online] Available from: http://gizmodo.com/156257/samsung-smart-zipel-refrigerator (Accessed: 15 October 2009)
Glyn Moody (2009) Should Software Developers Be Liable for their Code? [Online] Available from: http://www.linuxjournal.com/content/should-software-developers-be-liable-their-code (Accessed: 15. October 2009)
Francez Nissim (1993) Program Verification (International Computer Science Series) Boston: Addison-Wesley.

Share

]]> http://softwareengineeringblog.com/http:/softwareengineeringblog.com/software_engineering/liability-or-reality/52/feed 3 Different ways of thinking http://softwareengineeringblog.com/http:/softwareengineeringblog.com/software_engineering/different-ways-of-thinking/48 http://softwareengineeringblog.com/http:/softwareengineeringblog.com/software_engineering/different-ways-of-thinking/48#comments Wed, 25 Nov 2009 23:56:12 +0000 Laszlo http://softwareengineeringblog.com/?p=48 A program is a list of tasks to be performed by definition. But it can also be defined as a way of mapping a large task to shorter tasks. A computer always performs a program as a list of tasks. I take this question as a theoretical one. In my opinion the difference is the problem solver’s way of thinking. Let’s see a real world example. Assume, we have to sort a set of values. In case we try to solve it as a list of tasks, we probably come to a result, similar to the bubble sort algorithm. Paul E. Black (2009) gives a definition of bubble sort algorithm: “Sort by comparing each adjacent pair of items in a list in turn, swapping the items if necessary, and repeating the pass through the list until no swaps are done.”. This algorithm is an iterative way of solving the given problem. What happens when we try to map the large task to shorter tasks? Although there are a lot of sources where I can find this algorithm, I chose the same source because I think this dictionary is very useful. Conrado Martinez (2009) gave a definition of Quicksort algorithm: ” Pick an element from the array (the pivot), partition the remaining elements into those greater than and less than this pivot, and recursively sort the partitions.”. Divide et impera. Nice and elegant solution of the same problem. We can see the difference in the way of thinking. Both of them can give us a solution and both ways have it’s pros and cons. Recursion’s main drawback is the intensive memory usage. It is especially important in Java, my favourite programing language. Although Shawn Bayern (2001) writes about a very nice method of reducing the size of needed memory while keeping the code nice. I also have to mention another practical aspect. Although recursive algorithms are usually more elegant and many times it’s more easy to solve problem using them, they are usually slower as shiman (2008) wrote in his blog with some nice examples. He also summarizes the main cause of using the recursion: “Q: Then why use recursion?? A: It makes the code beautiful – recursion is a beauty of programming. Sometimes it is much simpler to write the recursive version.” Reference list: Conrado Martinez (2009) quicksort in Dictionary of Algorithms and Data Structures [Online]. Available from: http://www.itl.nist.gov/div897/sqg/dads/HTML/quicksort.html (Accessed: 15 October 2009) Paul E. Black (2009) bubble sort in Dictionary of Algorithms and Data Structures [Online]. Available from: http://www.itl.nist.gov/div897/sqg/dads/HTML/bubblesort.html (Accessed: 15 October 2009) Shawn Bayern (2001) Synchronized Recursion [Online]. Available from: http://www.ddj.com/architect/184404657 (Accessed: 15 October 2009) shiman (2008) Recursion VS Iteration (Looping) : Speed & Memory Comparison [Online]. Available from: http://shiman.wordpress.com/2008/05/28/recursion-vs-iteration/ (Accessed: 15 October 2009)

Share

]]> http://softwareengineeringblog.com/http:/softwareengineeringblog.com/software_engineering/different-ways-of-thinking/48/feed 2