Extensible Development

Knowledge is power, or for developers it’s skill. Or is it?

Before the time of Google developers were required to learn, remember and never forget the knowledge they needed to perform their work. I might be a bit of a dinosaur in that way, since I’d rather simply know than rely too much on Google. The media has reported cases of student relying more and more on Google (or Bing or anyother web search.) No longer is anyone required to know everything, the web answers all questions.

A fun example is something that actually happens around me sometimes. Since I live and work in Sweden many Operating Systems are in Swedish. Everything is in Swedish, even the error messages. That’s a great feat of the developers to successfully implement I18n, but sometimes other developers can’t find the solution to their problems because they don’t know the English version.

A well known expression in the programming world is RTFM, but this is becoming a relic of an older age, these days a new expression is more valid, STFG.

Unfortunately the expression “Knowledge is power” is still very true. Search engines hold more and more knowledge and thus power. Since it’s all free and open, there is absolutely no problem with that, in fact it’s great. It means everyone can share the knowledge. The real problem is that the people who are supposed to have the knowledge in their brains are become reliant on web search. What happens if the web is not accessible when they need it, or – god forbid – companies like Google and Microsoft start putting a price on that knowledge?

Yes, web search can solve many problems and provide a wealth of knowledge. But don’t just remember the URL to the knowledge you require, remember the actual knowledge instead. Reading news feeds about new techniques in HTML, CSS, JAVA, .NET, Ruby, etc. is great. But you should remember it, quite easy if you experiment with what you’ve read. Doing it stores more in the mind than reading about it.

Go ahead, STFG. Experiment, do, develop, extend and Remember.

Introduction

Image 1, Common tag line without any style problems.

Looking at the list of tags at the bottom of my posts, I noticed that when the amount of tags gets bigger, strange things happen to the style. When the text width gets too big to fit next to the category tags, it’s naetly moved down. But when it gets even bigger the text gets clipped. Changing the style so the text fits easily solved that problem.

Image 2, Wide tag line without any style problems.

.post .content .under span {
float:    left;
/* Make the span change height to prevent the text from being clipped. */
height:    auto;
margin-right:    15px;
/* Add padding to the left for the image. */
padding-left:    22px;
}

Image 3, Long tag line with wrong background.

But whoops, what’s with the background image? Using CSS Sprites and fluid/elastic layout doesn’t quite seem to work together…
Im my efforts to make this website’s themes more “elastic” I had to find a solution.
Read more…

Introduction

In “Document Management System in Word using WebDAV” I explained why I needed to connect Microsoft Word to a WebDAV repository and in “PHP based authentication for mod_dav” I explained how to set up authorisation for mod_dav using a PHP script. What’s left is accessing the WebDAV repository using Word’s Visual Basic. Read more…

Introduction

To be able to create a Document Management System in Word using WebDAV on Apache webserver, I did some research on mod_dav, an Apache module to provide WebDAV support. It appears that the authaurisation part of mod_dav is limited to “allow all” / “deny all”, which did not quite suite my needs. The solution needed more fine-grained authorisation on a per-directory level. Another problem was that the authentication and authorisation data was in a database. Read more…

Introduction

A customer I’m currently doing maintenance on their major application for, had an issue come up a couple of weeks ago where not all employees were to access all data any longer. The company deals with other companies and their employees, called members. The issue that came up caused a company wide policy to come in effect that meant that only specific users were to allow members or family of members to be accessed for a certain client company.

The application in question was easily modified since it already had support for authentication, so only authorisation for that specific company had to be added. (No we weren’t allowed to create a generic solution that would allow a reusable authorisation for multiple client companies. But discussing their policies is a whole different matter.) Read more…

I started writing my About page, but what I wrote started to feel like an article more than a short summary, so here is the full text:

What is “Extensible”?

Extensible is defined in Wikipedia as:

In software engineering, extensibility (sometimes confused with forward compatibility) is a system design principle where the implementation takes into consideration future growth. It is a systemic measure of the ability to extend a system and the level of effort required to implement the extension. Extensions can be through the addition of new functionality or through modification of existing functionality. The central theme is to provide for change while minimizing impact to existing system functions.

Although forward compatibility and extensibility are similar, they are not the same. A forward compatible system can accept data from a future version of itself and pick out the “known” part of the data. An example is a text-only word processor ignoring picture data from a future version. An extensible system is one that can be upgraded to fully handle the new data in the newer input format. An example is the above mentioned word processor that can be upgraded to handle picture data.

In systems architecture, extensibility means the system is designed to include hooks and mechanisms for expanding/enhancing the system with new capabilities without having to make major changes to the system infrastructure. A good architecture provides the design principles to ensure this—a roadmap for that portion of the road yet to be built. Note that this usually means that capabilities and mechanisms must be built into the final delivery which will not be used in that delivery and, indeed, may never be used. These excess capabilities are not frills, but are necessary for maintainability and for avoiding early obsolescence.

Extensibility can also mean that a software system’s behavior is modifiable at runtime, without recompiling or changing the original source code. For example, a software system may have a public Application Programming Interface that allows its behavior to be extended or modified by people who don’t have access to the original source code.

Although usually applied to engineered systems involving software, it can be applied to any type of engineering. Houses can be built with future extensions in mind. The Prince Edward Viaduct located in Toronto, Ontario, Canada was built to accommodate a future subway line.

Though the application to software is relatively new, the word has been a rare but valid part of English for a long time. The Oxford English Dictionary cites examples going back to the 17th century.

For me extensibility means, thinking ahead without planning the future. In the classic waterfall model, this would mean analysing all possible future feature enhancements and adapting the architecture to be extendable. This method always misses the target though and causes more problems and frustration along the road. My philosophy is that using development principles like Agile, Scrum, RUP etc. will not make the actual software extensible, but it will make the code much more flexible. Agile is used to be able to quickly adapt to changing needs (required feature priority, etc.) during development, but one thing that’s normally not mentioned is the timeframe.

If the development process is based around being agile, adapting to change and delivering production quality parts, does it matter if these changes come tomorrow, next week or next year? Of course not. The biggest issue with creating software that is future-proof is often not the actual architecture, but the code and the organisation around it. If code is well documented and the project around it is fine-tuned for quick change, then the code will become easier to maintain and adapt, thus becoming extensible. Often when we’re asked to make changes in (older) system the biggest problem is understanding the architecture and code in order to be able to make the changes. I’ve often heard of and seen systems that were extremely hard to maintain, so badly even that noone was allowed to touch the code and a complete new product was being developed instead. If those nightmare systems had been made using Agile/Scrum/RUP, then this probably would not have been the case. I say “probably” since there are people out there that implement Agile just for the sake of it without truly understanding it, this delivering even worse maintainable products.

What it comes down to is this: It’s not the code that makes a product extensible, it’s the process that creates it that does.