Tag: Philosophy

Houses of Cards

I have often heard of software systems being compared to a house of cards, meaning that they were poorly built and are ready to topple at any time. The system I am currently helping to maintain has from time to time also been labeled in that way, yet it always manages to go live with quite a few new functions, and apart from the odd all-nighter to fix a few last bugs, it works to the customers satisfaction. So while I was doing the washing up today, I noticed something. I am well known amongst family and ex-house mates for building what look like unstable piles of washed up dishes, as they dry. Yet I have never ever had a pile collapse on me. Never once have I lost it all. And remember, there are slippery suds involved in holding up these piles! As I thought a little more about it, it didn't take long to come to the simple conclusion that a pile of washing up is stronger than a house of cards. Cards are uniformly shaped and have no edges or surfaces which help to lock their neighbours in place.  Plates, dishes, cups, pans and cutlery on the other hand can be placed tactically so that they lock together forming a strong structure. Notice in the picture below that the heavy pan is placed at the top! It still looks ugly though. But as long as its just left to dry it will be safe. Just like our…

Read more

Creativity – Yet another driver towards agile processes

Software developers are often creative people, having entered into software development precisely because of its need for creativity during implementation. While solving a logical problem might sound unrelated to creativity, the ability to solve that problem in many different ways and choosing the right way, is what requires the creativity. This is what turns a mundane data entry job into an exciting and fun job. Not only are there many different ways to implement algorithms or user interfaces, so that they provide the same inputs and outputs as required, there are many different ways depending upon the architectural or design view points taken. For example, should the implementation use as much reusable code as possible, or should the code be as simple, readable and hence maintainable as possible? Or is breaking architectural policy allowed, in order to ensure maintainability, productivity or other aspects, etc... So if programmers, designers and architects are so creative, is it a problem? Well it can be, when requirements specifications are rigid. Developers need a certain amount of leeway in order to feel that they are being creative whilst doing their job. If a specification goes into exact detail about how to implement something (which a requirements specification shouldn't actually need to do, unless the requirement is defining the inputs or outputs of the system), then a developer can feel there is no need for creativity, and the fun part of their job disappears quickly. Once that happens, developer motiviation becomes reduced and project success starts…

Read more

NEWS FLASH: Agile does not mean there is no plan

Why aren't all projects run using agile methods? Working in an enterprise where we have maybe 50 applications which all go live at the same time twice a year (as well as another 450 which are also in some stage of the software lifecycle), I was told that it would not be possible to plan such a release without tight control over the planning, and frankly agile methods do not cater for such planning... Erm... I see it a little different. Agile to me means that there is a plan and you know the maximum amount of money that you can to spend. To me it also means there is a fixed deadline. As quality is also fixed (come on, it has to be bug free!), it is scope which changes. Or admittedly to some degree also quality, as you decide that some bugs are tolerable and you can live with them. What is different about agile projects, is that the project plan and scope (functionality) are alive. They are dynamic. They change from day to day as everyone on the project learns and discovers. Just like your day to day plans change as events unfold. It should be illegal for a project manager to state that a project plan is fixed. It shouldn't be allowed that the project manager, upon discovering that a plan needs to change, states that it will not be changed because it has already been communicated to the customer. This view is certainly un-agile. But…

Read more

The Key to Maintenance is Compartmentalisation

Over the last couple of large projects I have noticed a trend in the way software developers/engineers/architects like to come out with statements like "that code is shit". I'm not just talking about me saying it, or how they react to the code that I write (come on, I write great code!). But general sweeping statements like this crop up all the time on these projects, related to everyones code. And managers then perpetuate these statements. I think the reason is easy to understand. When a developer takes over responsibility for some code they want to make it clear that any problems with that code are unrelated to them. They don't want to take responsibility for the code which someone else has written. Because writing code is inherently creative and the same functionality can be written many different ways, you are almost guaranteed that a developer taking over some code "would have written it differently". What I have also noticed is that the developers coming out with statements like this do not know or do not want to understand the conditions under which the code was originally written. As an architect, I realise there are many many factors which influence the creation of code, budget being a major one. What some developers also do not fully appreciate is that the perfect implementation not only doesn't exist (because every developer would do it differently) but that it often isn't required. The perfect solution considers many cases which don't need to be…

Read more

Complexity makes for exponential maintenance costs?!

The title of this article isn't a fact, just a thought. However the thought comes from the experience of putting a very complex application into production and watching what happens. So long as there is stuff to do on the application, e.g. further releases adding more functionality, the maintenance costs are minimal, because you can plan the people who do the maintenance to do spend say 20% of their week on maintenance tasks while spending the rest of their time on building the new functionality. But what happens when there is no more new functionality to build? What happens if suddenly there is no budget for new functionality? Well, you normally scale down the team, reducing head count to the minimum required to keep the knowledge about the application. You will probably put them part-time on other projects. But now it gets hard. If the application is very complex or uses many differing technologies, it might not be possible to efficiently (in terms of reducing knowledge loss) reduce the size of the team below a specific size. If you application uses say a BPEL Engine, an Oracle Database, a Java Application Server, has a web front end and connects to several external business partners requiring knowledge of complex business rules, you probably already have the requirement to keep more than five people for maintenance. Mostly, this doesn't cause a problem, because those people can happily staff other projects. But if the application is so complicated that they are certain to…

Read more

Extreme Productivity

A year ago I was the architect of a small project (Project A) building a Client / Server application, based on Eclipse SWT/JFace/RCP, Websphere, Oracle, JMS and an Object Relation Mapping (ORM) tool, Hibernate. We were 3.5 developers on average, and we finished in 7 months. We used Feature Driven Development (FDD, similar to eXtreme Programming) as its implementation methodology. This year I worked as a lead developer on a much larger project (Project B), which I joined in its second half. The project as a whole had nearly 50 people on it at times, although our part was again an Eclipse SWT/JFace/RCP Client using a Websphere Server with Oracle and a different ORM tool, Toplink. We were 5 developers on average, finishing in 9 months. Here a kind of waterfall based methodology was used. In my spare time, I work on a tiny project, BookStore. Again an Eclipse SWT/JFace/RCP Client but not using Websphere, and instead of Oracle it uses MySQL but also with Hibernate. Its developed by just me. I do however track time spent on implementation, as well as metrics. The methodology used here is an extremely Agile one, where the documents are in the code (unless its really major, then it gets its own document), priority is given to bug fixing, then feature development, then product improvement. The aim is to be able to release a stable version at any time so that bugs can be fixed super quick. The product auto-updates from the web, to…

Read more

The End Draws Nigh

As we start seeing the light at the end of the RMR tunnel, we are on time, on budget! But is it purely down to my masterful planning and estimating skills? Or are other factors at work? Well the planning is in the right ball park, but as I started to ask myself if we could have finished any earlier, two things dawned on me. 1) Project Teams work to a given deadline and are unable to realign to an earlier one 2) Although Quality, Cost and Funtionality are all within the required boundaries, there are ways to cut corners without affecting them, when viewed from a high level (e.g. the project stakeholder) In terms of the former, I think it is well known that if you assign a task and allow a given time for it, it is very likely to take that long if the time allocated is realistic. It takes dedicated individuals with something to win by delivering early, in order to do that. The latter point relates to having loose requirements specifications from the customer, and moving requirements driven by the development team as we designed and engineered the solution.  It is relatively easy to convince a customer how to change the system to make it easier to develop, when he cannot sit down and play with it to see if the proposed solution will work for him. It's like building a kitchen and negotiating using a different cupboard that is easier to install. If it…

Read more

Requirements Gathering geht schief!

If requirements are gathered by someone who isn't an end user, but who is an expert in the domain, there is the likelyhood that the requirements will be only roughly accurate. If that gatherer then leaves the project and you lose touch with the end users, your'e even more likely to lose your way. On a number of occassions I have seen the end users arguing with the developers as a project comes to a close, over whether what was implemented was what was required. More frequently than not, the system will do what is required, it's just that it does it in a different way. There is more than one way to write a Word document for example! Systems that are complex naturally have more than one solution. It depends on how the persons implementing that solution think - their entire background, culture and education can affect the solution. A fully trained kitchen fitter might have a very different perception of how a kitchen design system should work compared to a software Architect, Developer or Business Analyst. But if the system allows them to design a kitchen, is it relevant if the dialogs, screens, functions and/or business processes of the system are different? Take an SAP system for example. These come preconfigured with thousands of business Processes, Forms, Dialogs, Data Models, etc. SAP allows for example, a company to implement a Supply Chain application. But there are many, many companies which have changed their business processes to match their…

Read more

System Colours

We had an interesting experience on our project a few weeks ago. We asked the users for colour specifications for the GUI. Now bearing in mind they have been using a system that is 20 years old, they came up with "green back ground", "blacks", "grays", etc. Here is a demo: OK - I admit I used the brightest green I could find, but the point was that with modern look and feels, we thought it would be better to stick with default colours: Lessons learned? Work closely with the customer but don't be afraid to recommend the sensible options when they arise.

Read more