HTML5: The future of the Web is finally here. But, can they compete with native apps?

I read an article on CNN Money about future of HTML5. The article is too rosy about HTML5, in my opinion. What the article doesn't talk about is the abandoning of HTML5 by Facebook and by Google to some extent. With desktop nearing end of life, mobile is the future. Google mobile search has surpassed desktop traffic. And, in mobile we mostly use native apps against HTML5. How many time have you opened the mobile browser and checked your gmail or facebook or pinterest or any of your favorite/frequently used services? It's native apps most of the time. So, HTML5 is great, but not strong enough yet to compete against native apps.

You can read the full article i am referring to here -- HTML5: The future of the Web is finally here - Dec. 17, 2012

Clever code is Hard to Maintain... and Maintenance is Everything

Disclaimer: Published under and in conform with Creative Commons Attribution 3 license. Originally published by O’reily media as a part of the book “97 Things Every Project Manager Should Know”. Author’s grammar and punctuation kept.

Developers are often asked to create miracles. They must find clever ways to make today’s project code work with yesterday’s antiquated, legacy software containing multiple patches. And through skill and ingenuity they may create numerous lines of clever code that finally get the job done. But clever code may only create future maintenance problems due to the code’s length and complexity. There may be a better way.

If you are a project manager new to software development, don’t be afraid to let developers explore new languages and development tools. Allow them this freedom, because this is how they discover innovative ways to improve their coding practices and results. They may be able to design a software solution to your legacy interface problem that is faster and has fewer lines of code to test and maintain. This is certainly an advantage to your project.

There are innovative new programming languages that can perform the same functions as your current ones with substantially fewer lines of code. This is of value in that a simpler code structure is easier to test, can be self-defining, is smaller to store, and is easier to maintain.

Obviously, there are some concerns about adding new languages and platforms within your organization. Will this new code truly solve the problem for the current software or upgrade under development? Will it interface long-term with the existing software used in your legacy databases, user interfaces within the organization, and third-party software in which the company has already invested?

Are there other developers on the team or the department who will be able to create software in this language or on this platform? Is there adequate product support from language authors? Will there be timely updates and improvements?

Even if you are not familiar with programming yourself, don’t be reluctant to allow programmers to embrace new languages. If the new language can trace its tortured lineages back to C or Java (or any other common way of doing things) is probably going to be relatively painless to merge it into your current practices.

However, be sure to document any new practices within your code. Otherwise, your code base and the documentation about the code may diverge to the point that the best way to understand the system is to look at the code itself. This is called a "loss of coupling" between the software components and system metadata. And when there is inadequate documentation to maintain your software system, it must be replaced.

Encourage your project team developers to be innovative, but not clever to the point of excessive complexity. Being too clever makes it hard on those who follow. If later developers can't read the code, how can they be expected to maintain it? Any given programmer may try to be clever to enhance their job security, but no project manager will benefit from it.

Code that is too clever will ultimately be too hard to maintain. That leads to maintenance failure and a costly reworking of your software systems.


The author of the original content can be found here