Introduction

In “[intlink id="64" type="post" target="_self"]Document Management System in Word using WebDAV[/intlink]” I explained why I needed to connect Microsoft Word to a WebDAV repository and in “[intlink id="43" type="post" target="_self"]PHP based authentication for mod_dav[/intlink]” 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. Continue reading →

Introduction

To be able to create a [intlink id="64" type="post" target="_self"]Document Management System in Word using WebDAV[/intlink] 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. Continue reading →

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.) Continue reading →

The current economy  is forcing companies to take desparate measures to ensure their survival. The further down the employee chain the less ideal these measures seem. I’d like to analyse this and offer a possible solution.

Most companies, especially larger ones, tend to see cutting down the number of employees as the first solution, or so it often seems. Luckily more and more companies are really investigating all the possibilites to their disposal to decrease internal loss and increase revenue. The question is, are they really doing everything they can? I’m convinced that this is not the case, often far from it.

Continue reading →

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.

Last week Åsa, a colleague at Steria Sundsvall, had a link to a great article by Kelly Waters: 3 Reasons Why I Wouldn’t Do Agile Software Development.

…
There are some circumstances where an organisation’s culture is possibly too different to successfully adopt agile. At the moment I can think of only 3 reasons why I wouldn’t do agile software development:

1. If I was working for an organisation that believed it needed complete clarity about a solution before it could start a project. I believe this is a false positive, and it would be very hard to adopt agile in an environment where key stakeholders insist on this.

2. If I was working for an organisation where the relevant product owners couldn’t – or wouldn’t – commit to being actively involved throughout the project. I really do believe that active user involvement is the first principle of agile, and imperative for a project to succeed.

3. If I was working with a team that I didn’t believe could cope with ambiguity, or didn’t have sufficient communication skills to collaborate effectively with business colleagues or customers.
…

This week I hit number 1. The past 2,5 months I’ve been working at Statens Pensjonkasse in Oslo Norway.
From now on the team I’m in will be completely responsible for the production and delivery of new maintenance releases of the main application used by SPK. We went through the process of producing, testing and delivering the next version and something very interesting came up…

A complete new version of the application (front, middle and back-end) is being made by another group – a quite large group where Steria Norway is also involved – using Adobe Flex and Java. The project is called Perform and uses modern technologies and techniques, Scrum among others.

When we took over maintenance of SPK’s current system, they gave an introduction course to Scrum and said it was up to us if we wanted to maintain their application using waterfall or Scrum. As an agile evangelist and ScrumMaster I of course felt the urge to choose Scrum, but was that right?

Until now the entire maintenance period had been quite ad-hoc with lots of Service Desk issues coming in and ad-hoc solutions being needed. (But that’s another story…) This meant there was no real opportunity to think about the development process. But now that we’re taking over as maintenance release team and need to plan more ahead, I had assumed we’d go Scrum. That however, seems quite impossible, even quite unsuitable.

The way new releases are prepared is quite glued to the waterfall development process that has been used until now and as we see it, that cannot be changed. Yet. (I’m not giving up hope.) The customer first gives us a list of open issues that need to be a part of the next release, we estimate the time required, they approve, we build. Then the testing starts… Testing is done in at least 2 phases, system test and acceptance test. We learned that both are done manually and that they’re identical. During the system test phase a person manually goes through all the tests, if all tests pass someone goes through all the tests again but calls it acceptance phase. This hair raising principle is the main reason for not being able to apply Scrum, since it cannt be changed. It may be possible to change it later, but that might take a year and this version of the application is planned to be superseded by Perform in a few years, so it doesn’t really feel like it’s worth the struggle. Just for the experience and sake of Scrum I should try, but probably won’t.
The reason the production and testing procedures are as is, is because of how the application has designed and written. Almost all of the functional code is written in C and embedded SQL. C is hard to fit into Continuous Integration and the embedded SQL is so complex that we dare not even think about mocking/simulation or automation. (A typical SQL task runs for at least 10 hours before any results/errors can be seen.) Even if we did manage to rewrite the code so it was testable with CI, the environment the building (make, nmake) run in and the application environment are so hard-coded that it would take weeks to make it more modular and portable (with portable I mean being able to build and run anywhere without breaking dependencies). (The windows client build process has dependencies that are only built in the Unix server process, but that discussion is off-topic.)

It is quite a shame, but Scrum is not the way to go this time. At least we’ll be able to use Scrum internally while implementing the next release, since Agile/Scrum can always be applied within a waterfall (or other) wrapping.