I like the wording of the ruling made by the EU court system in this regard. They support “reverse” engineering in the sense that license holders of software can tinker around with the product to the point that they better understand how it works. Any derivative works that come from that understanding isn’t copyright infringement. Way to go!
Computerworld - Europe’s top court has ruled that the functionality of a computer program and the programming language it is written in cannot be protected by copyright.
The European Court of Justice made the decision in relation to a case thatSAS Institute, a maker of statistical programs, brought against World Programming Ltd. (WPL), which develops and sells an interpreter for the SAS language.
Although WPL used and studied SAS’s programs to understand their functionality, the court said, there was “nothing to suggest that WPL had access to or copied [SAS] source code.” The court ruled that “the purchaser of a license for a program is entitled, as a rule, to observe, study or test its functioning so as to determine the ideas and principles which underlie that program.” … (read more)
I think this ruling will better support more innovation and make life less stifling for talented developers looking for a better way of accomplishing business level tasks other than subscribing the status-quo of a handful of big vendor products. In turn, it will keep the big vendors on the alert and responsive to their customer base because they can quickly be replaced by a better engineered product.
Picasso’s famous saying is penchant to the old-school mentality of the artistic community. Artists were once hiding their methods, techniques and styles as trade secrets locked deep within their works. Now, with the advent of digital art media there is a new trend of creative artist emerging. You have probably already heard of “open source” software. This is the same, only applied to software used in the creative process by many artists.
Artists are notoriously secretive about their processes. Rothko never revealed the complex formulas behind his diaphanous color fields. Picasso gave his famous dictum, “Bad artists copy. Good artists steal,” which may have been why Brancusi was so loathe to let the Cubist into his studio. But what about when sharing becomes a fundamental part of the artistic practice? For new media artists, whose work embraces the latest innovations in computing technology and digital imaging, being transparent with their working process is a fundamental part of being a member of the creative community — everyone copies and adapts from each other, sharing strategies, tools, and techniques… (read more)
The idea of open-source projects as the new media of digital art forms encourages collaboration over secrecy… a revolution in the highly competitive, art making world. Glad to know that us software developers had a thing or two to teach these folks purely from our collaborative culture.
Just a few thoughts on one of the emerging “agile” software project management methodologies out in the field today. Scrum seeks to follow a rapid, iterative approach which involves the customer interactively along the development process to make sure that requirements and project scope are carefully tuned to the customer’s expectations.
Scrum at a High Level
Scrum is an “agile” process that allows us to focus on delivering the highest business value in the shortest time.
It allows us to rapidly and repeatedly inspect actual working software (every two weeks to one month).
The business sets priorities. Teams self-organize to determine the best way to deliver the highest priority features.
Every two weeks to a month anyone can see real working software and decide to release it as is or continue to enhance it for another sprint.
Learn Scrum in 7 Minutes!
The following video gives a informative take on the Scrum software project management methodology. While I do not know the folklore behind the use of “pigs and chickens” as the characterized project workers, they are commonly used symbols when the concept of scrum is explained or discussed.
More Background on Scrum
Scrum is an agile software development model based on multiple small teams working in an intensive and interdependent manner. The term is named for the scrum (or scrummage) formation in rugby, which is used to restart the game after an event that causes play to stop, such as an infringement.
Scrum employs real-time decision-making processes based on actual events and information. This requires well-trained and specialized teams capable of self-management, communication and decision-making. The teams in the organization work together while constantly focusing on their common interests.
Scrum involves:
Initial appointment of a project manager called the “scrum master.”
Definition and prioritization of tasks to be done.
Planning sessions for each task.
Daily meetings among teams.
Identification and evaluation of potential project risks and process pitfalls.
Execution of projects in brief, high-intensity, frequent work sessions.
Reviews of progress and evaluations of completed projects.
Openness to constructive criticism and ideas for improvement.
The scrum concept was introduced by Hirotaka Takeuchi and Ikujiro Nonaka in a 1986 article in The Harvard Business Review, “The New New Product Development Game” The original context was manufacturing. Jeff Sutherland, John Scumniotales and Jeff McKenna are credited with adopting, implementing and documenting the model for software development at Easel Corporation in 1993. In 1995, Ken Schwaber presented an influential white paper at OOPSLA, “SCRUM Development Process.”
I have had most of my experience with waterfall methods, but I can see some value in the agile approach. The big difference between the two is that in agile projects, evaluation of a module is present before it is passed along. In Waterfall, there is no stopping and the project flow passes along with hopes of a good outcome. In Waterfall, the linear approach makes it harder to go back when a downstream team or group meets with a major problem or roadblock caused by decisions made during earlier tasks.
Many ideas, disciplines, techniques, tools and terminologies are a part of the last fifty years of our field. How much of it do you know? You should know a alot of it and be expanding this set of knowledge each day. Though our field is progressing rapidly in the periphery, a lot of basic concepts remain relevant.
Some of these ideas have been sidelined for favor of others but very few have been considered completely irrelevant. These ideas are still important and valuable to know what they are as well as their strengths and weaknesses.
Remember the saying: “Those who cannot remember the past are condemned to repeat it.” Take it to heart and try to understand some of the heritage behind the development of our field.
From the book “The Clean Coder”, here’s a few recommendations on things that every software professional should have an understanding of:
Design patterns. Be able to describe all 24 patterns in the GOF book and have a working knowledge of many of the patterns in the POSA books.
Design principles. Know the SOLID principles and have an understanding of the component principles.
Disciplines. Practice TDD, Object-Oriented design, Structured Programming, Continuous Integration and Pair Programming.
Artifacts. Know how to use UML, DFDs, Structure Charts, Petri Nets, State Transition Diagrams and Tables, flow charts and decision tables.
These aren’t an exhaustive list but they represent a core of knowledge that is a integral part of the history behind modern software design and development and the evolution of its practice.
Two simple guiding principles should be kept in mind when implementing dimensional database design techniques: accuracy and performance.
The accuracy of a design is important for several reasons. While operational questions asked of the database can be determined in advance with some level of certainty, analytic questions cannot. Analytic questions often change with time and questions lead to even more questions.
Designers need to keep track of how the facts in a database are represented. Is there a chance that the data can be misinterpreted or misapplied through either a false query assumption or understanding of the data? What kinds of design methods can be implemented to eliminate or reduce ambiguity or confusion of the use of the design’s facts and data?
Also of importance is performance. The results from queries against a dimensional design are usually optimized due to the structure of its tables and objects, but since the nature of questions asked of the database changes with time, constant effort needs to be invested in optimizing the response time of these evolving queries. Performance considerations may lead designers to consider offering multiple formats of the same data to support these variations in query scope and type.
In an article from the SD Times, author Victoria Reitano cites two recent studies made by CAST, a software analysis and measurement firm who recently reassessed security weaknesses from a pool of web and mobile applications available on the Internet today.
The study did not pinpoint any software language in general, but they did highlight that languages such as Java seemed to be the heaviest of the code bases which had the most defects. One possible reason could be that the programmers who are coding in Java are from a younger generation (such as fresh college graduates or still in school) where not enough industry experience with hardening systems is accumulated.
Neil Mac Donald, vice president and analyst at Gartner, said that because security is not a part of most college curricula, companies should take the time to invest in training their developers.
The aggressive nature of mobile and web app development was also cited, as this group of software products ranked highly with “technical debt” (technical debt is the estimated cost in development resources required to fix high-risk issues that appear in a line of code.) It seems that security becomes a heavier and more impending task which needs to be integrated into ever tightening and shortening development cycles for these software products. It appears, in conclusion, that given less time to develop apps, the concept of security gets left out of the initial efforts in the general “rush to market”.
The second most recent survey of software applications revealed the following findings:
32% of all web applications tested had SQL Injection threats, while
68% had scripting vulnerabilities.
40% of the vulnerabilities found in government Web applications are from SQL Injections.
SQL Injections account for 29% of the vulnerabilities in finance applications and 30% in software industry applications.
One additional trend observed is that Android (mobile) platform code recently surveyed are showing signs of similar weaknesses observed in early programs written for web-based applications.
Gartner’s MacDonald said “Coding security [into applications] doesn’t have to take more time,” adding that there is a perception that doing work quickly means leaving out steps that are not mission-critical, but that is not the reality. He said that developers can do work quickly and add the proper security measures.
Mac Donald also goes on to blame that companies are also resistant to change because of short-term gains that can be obtained from short-cutting and bypassing the integration of security consciousness in their software development efforts. It will most likely be a combination of “people change, process change and technology change” to cross the gap needed to increase security awareness among the developer culture.
