Random Acts of Architecture

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

Tag Archives: Open source

Floundering in Alphabet Soup Part I

Alphabet SoupThe IT industry is swamped by certifications. Every conceivable three-, four- or five-letter acronym seems to mean something. However, everyone can recount a story of someone certified but clueless. In a world where answers are often a quick Internet search away, are certifications still relevant?

Certifications aim to show someone knows something or can do something, like configure a device or follow a process. Condensing a complex product, process or industry into a test is hard. Schools and universities, dedicated to learning with larger budgets, have been grappling with this for some time and even multi-year degrees are not always good predictors of competence.

Knowledge atrophies and conditions change. While some certifications require periodic certification or ongoing training to keep candidates current, there is no way to guarantee someone maintains or improves their skill and their knowledge is current.

Certifications risk devaluing experience. For example, the Microsoft Certified Systems Engineer (MCSE, now Solutions Expert) boot camps of the 1990s saw many inexperienced candidates spoon fed the minimum information to pass then unleashed on an industry expecting people more capable. Why hire someone experienced when you can hire a newly minted MCSE at a fraction of the price?

Certifications are no longer the only way to demonstrate competence. Speaking opportunities at user groups, social networks and blogging are open to anyone. Online training websites like Coursera or Pluralsight provide similar or identical material to common certifications at no or minimal cost. For a more specific example, a software developer that wants to demonstrate competency in a library or programming language can contribute to open source software or answer questions on Stack Overflow.

Many candidates complain about excessive certification costs, particularly for not-for-profit certification bodies. Certifications are expensive to create and administer, particularly minimizing cheating, and to market, because an unknown certification is wasted.

Does that mean certifications are dead? No. Certifications continue to have the same benefits they always had.

Certifications give you credibility. While saying you know something is easy, becoming certified is a known, third-party verified benchmark. Harder, time-consuming and/or hands-on ones like the Cisco Certified Internetwork Expert (CCIE) or Offensive Security Certified Professional (OSCP) especially so. They are good personal development goals.

Certifications make you more marketable. Many employers look to them as shortcuts for skills. Hiring someone certified decreases risk. Couple with experience or aptitude, they may lead to increased pay or new positions. They can even be a personal brand. For example, putting a certification next to your name on LinkedIn immediately tells the viewer your career focus.

Certifications open new networking opportunities. Certifications identify people with common interests or solving similar problems. Meetups, conferences and training courses target these. Some give discounts to certification holders, too.

Certifications tend to give rounded and broadly applicable knowledge, including different technologies, business areas or perspectives. They usually reference authoritative information and cover best practice, albeit sometimes abstracted or out of date. This can be harder to Google for because it requires domain knowledge.

Certifications benefit certifying authorities, too. From a vendor’s perspective, certification programs ensure product users are competent by requiring partners and resellers to have certified staff. Periodic recertification or certification expiry forces users to be up to date and creates recurring revenue.

The existence of certifications indicates a product’s or market’s maturity. They can help standardize, unify or legitimize a fragmented or new discipline. Certifications are as much a marketing tool as technical.

They allow vendors to identify and communicate directly with the user base. Vendors often know their customers (who is paying for the software) but not the people using it.

Certifications are not going away and are still relevant for the same reasons they always have been. They can still be a differentiator and misconstrued. They are still useful to vendors but expensive. However, the real question is how the current alphabet soup needs to evolve and still be relevant in the constantly changing IT landscape, particularly for areas like software development with a poor certification track record. That is something for the next blog post.

Image credit: http://www.flickr.com/people/bean/. Usage under CC BY-NC 2.0.

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?

The Other Side of Software Architect Innovation

As stated previously in this blog, software architects must be innovators. They are responsible for creating a technical vision to apply new technologies to further the customers’ goals and/or reduce development costs and for high level designs. Many books, lectures, blogs and so on describe the process of innovation and are not repeated here but, when confronted with a problem, most developers and architects either work out their own solution or lazily Google something similar. However, software developers and architects, in particular, need not “reinvent the wheel”.
 
Ignoring structured learning, such as degrees and certificates, there are two ways architects can learn ways others do things. The first is to proactively listen for new information.Most software architects will already read favourite blogs or web sites, follow twitter luminaries, subscribe to magazines, read textbooks, attend conventions and so on. However, the key with information sources is efficiency – five sources providing predominantly relevant information is better than one hundred poor sources.
 
Aim for a mix of information sources, including some technical, some design, some industry commentary and some aggregators (those that provide interesting links to other sources that may only occasionally have relevant information). Review sources over time because the architect’s requirements, knowledge and expectations will change over time. Experiment with new things and plan to either remove “old favorites” or check them less often when they are no longer being consistently useful.
 
The second is to research topics when the need arises. Competitor’s products are good places to start but, unless this is a major feature, information is often sparse. Internet searches or dedicated development sites are useful but iterating synonyms is time-consuming.
 
Software architects often neglect academic texts or papers, which are particularly useful if the group is using more complex algorithms. Use Google Scholar or consider joining ACM or IEEE to access their academic paper repositories. Such papers may be dry or assume too much knowledge initially but persisting may reveal better approaches, establish common terminology and point out less explored areas suitable for potential patents or the architect’s own academic papers if he or she is so inclined.
 
Some would recommend looking at open source software. Assuming the product is chosen with care, open source software or other people’s code in general is a great source of information from obscure language features to new algorithms. However, the software architect must not copy any code verbatim or infringe patents or licenses.
 
If the problem is not solved or not solved sufficiently by prior art and the organization has a process in place, software architects should create and file patents. Arguments over whether software patents encourage or discourage innovation are irrelevant. As they say, “You cannot win the game from the sideline”. The IT industry is pursuing patents aggressively and companies that do not, such as Google with Android, now face legal challenges and hurdles. For the software architects, patents are one of the few peer-reviewed, universally available measures of creativity available. Many organizations also offer financial incentives for them, too.
 
Beyond the software architect’s products and patents, avenues for innovation include open source software, apps in app stores, writing a technical blog, conferences or academic papers. Approval may be required from the organization and social networking activity will need to comply with the organization’s policy but this can help the software architect’s personal brand and help find or precipitate conversations with like-minded individuals.
 
The single most important thing about innovation is to start. A software architect must be a technical leader but cannot lead without producing and cannot produce without starting. The first attempts may be unremarkable or unsuccessful but persistence will bear fruit.
%d bloggers like this: