Random Acts of Architecture

Wisdom for the IT professional, focusing on chaos that is IT systems and architecture.

Tag Archives: Ownership

Intellectual Property Ownership

Whenever anyone involved in intellectual property starts a new job, particularly in software development, the employment contract usually includes a lengthy intellectual property agreement where the new hire assigns ownership of all intellectual property created over to the employer. Many new employees balk at this, concerned that the employer will claim any side projects they are working on and with recent court battles over software patents worth billions of dollars, for example, intellectual property ownership is a complex area worth exploring.

Employment contracts are usually “work for hire” contacts. Although the legal requirements and obligations vary from country to country, it usually means the employer owns any works created instead of the employee, in return for payment or salary. Few software developers dispute this. However, unlike authors and artists usually contracted for a specific work, developers are often contracted for all intellectual property created during their employment, irrespective of whether it is performed during working hours on work equipment.

Software developers are increasingly working on side projects like open source software or apps for mobile or tablet app stores. Many developers code in the spare time, whether it be tweaking the website for a friend’s business or experimenting with new libraries or languages. It is also increasingly common for students to bolster their resume this way or for software developers to teach themselves new languages or libraries.

This differs from traditional “working under the table” or “moonlighting” in that much of the work is not paid. The software developer may want to capitalize on the work in the future but usually just does not want others intruding or demanding ownership of the work, akin to a lawyer doing “pro bono” work. Software developers are also producing assets other than code. For example, software patents produced during software development can be more valuable than the code.

The barrier of entry for software development has never been lower. Thirty years ago, software development was difficult, usually performed on expensive, centralized computers and proprietary software. This is a far cry from today where one can create complex websites using free tools running on free operating systems hosted on commodity priced servers. Compare that to chemists, physicists or engineers that may require thousands or millions of dollars of equipment and dedicated teams of support staff to perform their research and yet more to monetize it.

Indeed, the problem with software patents and intellectual property ownership in software development is development only part of the cost. There is the marketing and sales required to turn products into revenue, for example, and the IT infrastructure, HR and accounting structures required to support all of this.

Patents are similar. Beyond software development, legal expertise to file patents is required along with the time and resources needed to find and deal with infringements. Patents are also often cross licensed, either earning additional revenue or allowing access to other organizations’ patents. Patents may also become more valuable over time as products they are used in become more widespread.

The word “ownership” also carries many mis- and preconceptions. If an employed software developer (“inventor”) wants to own all or part of his or her inventions, what does this mean? Does the inventor want royalties, like an actor may receive for a movie? Does the inventor want the option to use it in their own work, possibly for a job at a competitor? What about an open source project the inventor contributes to in his or her spare time? Does the inventor want the option to stop others using it, like competitors or those the inventor disagrees with? Will the developer help fund the sales, marketing and legal infrastructures required?

Even if those in software development can make a case for increased “ownership” of their products, it is not in employers’ interest to allow this. The creative process cannot be constrained to occur within work hours or on work equipment – many have  inspiration when asleep, exercising or in the shower – and increasingly flexible working arrangements further blur the distinction. Work for hire contracts are also well understood and widespread, making them lower risk.

Some would argue software development is like a painting selling and reselling for increasing amounts but the original painter seeing none of the profit.  However, a better analogy is performers selling music. Do they go through a record label where they get greater exposure and marketing but sacrifice income or do they produce the songs themselves and sell it through iTunes, where they can make a greater cut but a much reduced sales volume?

Many employers are also quite reasonable. If the idea is unrelated to current or likely projects and the employee is not going to make much money, pursuing it is not worth the expense. If the organization files patents, most reward developers with bonuses for doing so. Other employers take the opposite position and talking to the employer first before producing anything important is prudent.

It will be interesting to see what the future holds. Younger generations, those that have grown up with social networking, are used to sharing their lives on social media and regularly blur the lines between professional and social. With software development tools more accessible than ever and collaborative source code repositories like github gaining in popularity, will developers from younger generations look at coding the same way? While they may have different politics from their GNU and GPL espousing forefathers, will they see “social coding” or “social software development” as an obvious direction? If so, what compromises will be made?

Priming for Effective Feedback

Ignoring software architects’ code, the primary deliverables of architects are technical vision and high level designs. These are rarely complete and correct in the first draft and getting feedback from stakeholders and developers is vital to their success. Indeed, the best software architects are those that consistently extract the best feedback.

The key to effectively receiving feedback is for the software architect to change his or her attitude to feedback, particularly criticism. A software architect’s job is to own the problem, not a solution and providing the best solution, even one that contains elements from others, is the goal. When people give feedback, it means they are invested enough to care about the topic. By comparison, a lack of feedback or dismissive, detail-lacking response, such as “Looks good”, usually means the document has not been read or the reviewer is not invested in its success.

First, identify why feedback is being sought on the document, presentation or similar. Be more specific than just “standard procedure”. For example, is this a customer facing document that must not include company confidential material? Meeting minutes where important details and decisions need to be captured? A radical, new, partially-developed idea to create discussion and spark other ideas? This will dictate the audience and direct their attention.

Then identify what sections or details the reviewers should focus on, particularly for larger documents. Otherwise, some will focus on “big picture” issues, spelling and grammatical errors or otherwise get distracted. If uncertain, start with a high level introduction then focus on potentially controversial aspects such as assumptions, integration points and major decisions. If a document has multiple audiences, consolidate information for different audiences into separate sections for clarity and provide context if needed.

Given the above, many send out the document as an E-mail attachment or link, cynically expecting no response. There are two issues with this. First, typing responses can take time, be prone to misunderstanding and some people just do not communicate well in this medium. Second, without an articulated deadline, many will forget about it.

The solution is to still send document as E-mail attachment or link around but organize one or more meetings or conference calls, the latter preferably with document sharing software, to discuss it. Some will still respond with questions or comments before the meeting. However, the meeting gives people a deadline to review the document by and allows those that prefer verbal feedback to do so. Not everyone will find all issues with the document and a meeting allows feedback to be shared by all members of the group and not just the reviewer, potentially sparking additional ideas. For long or detailed documents, multiple short meetings are preferable to fewer longer ones. It avoids fatigue and fits in better with busy schedules.

Indeed, feedback is a conversation, not a download. The software architect, or whomever is providing the reviewed document, must provide a timely response and to a wider audience if warranted. If the architect is not detail-oriented, enlist the aid of someone who is to help keep track. Disagreements or contradictory feedback are learning opportunities and usually the result of missing information, assumptions or different experiences. In this case, either identity the facts that all parties agree on then build up from there or use an external expert or trusted authority.

Honest feedback requires safety. Architects are often senior developers with lots of experience and can be intimidating, particularly to junior developers. Remind others that you welcome feedback and emphasize other’s contributions to the document. Paraphrase feedback to confirm understanding. Humor, if culturally acceptable, can be a great tool if not overused, too.

Feedback requires mutual respect. An architect that disrespects a reviewer is likely to dismiss their feedback without adequate explanation or justification, impacting safety as mentioned above. If the experience or knowledge gap between reviewers is high, separate the reviewers into groups of similar capabilities then adapt the document or meetings for each audience. Often those with the best feedback are those that failed at something similar because they generally know why they failed better than those that succeeded know why they succeeded.

Similarly, reviewers that disrespect the architect may use it as a point scoring opportunity. An executive or customer may dictate rather than discuss. In these cases, paraphrase the points made to ensure understanding then agree to delve into more detail later in a dedicated meeting. Strong emotion may also be symptomatic of underlying issues probably beyond the scope of the document being reviewed.
%d bloggers like this: