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…
Tag: Architecture
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…
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…
White Papers
I have just uploaded two papers: Agile Software Development of Service Oriented Architectures, Business Process Models and Enterprise Service Buses Service Oriented Architecture Strategies They can be downloaded from: http://www.maxant.ch/white-papers
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…
Reporting Stats
A few years ago when I was the integration architect in charge of my Global 500 customers EAI projects, the product that we used did not really offer any way to track the number of messages travelling through the system. To get around this, we added a little library that recorded a small amount of information about each message. The idea was that every application (message flow) within the EAI system would be instrumented with this code and we would gain an oversight over which interfaces were the important ones and which ones made a return on their investment. The sort of data we collected was: Interface / Application / Process Name Message Type Message Size Timestamp Status (eg. IN, OUT, SUCCESS, FAIL) Correlation Token (in case several messages belonged together) Error (ie. details of an error) Custom Data (specific to each interface / app / process) There was probably more... it was a few years ago now :-) Anyway, we soon discovered that there were applications that were not even being used, even though our customers had paid many tens of thousands of dollars for them (ok, I admit that isn't a lot of money in the IT world). Since then Google has created its "Analytics" offering which generates some excellent reports for web site statistics. Indeed, maxant has always collected web stats for the websites it runs. It is very important to know your users / customers usage patterns, in order to be able to understand their real…
OSGi – Just another fad?
In the last few weeks I have heard the term OSGi come up more and more, and one blog posting I read suggested that it was the hot topic of 2008. So I started to research a little. I am currently working heavily with the Eclipse Rich Client Platform building applications which use services deployed to IBM WebSphere. Both these platforms are built up on OSGi (the standard) and both use Eclipse Equinox (an implementation of the standard). So it must be important right? Well you don't have to read too much before you start to get the feeling that you have been there and done that before. One aim of OSGi is to provide a micro kernel for deploying and managing services. Well, from a high level, JMX (MBeans) already does that. Not enough? Well there used to be a project called Apache Avalon Phoenix, which was a mirco kernal and although that project died and was resurrected as Loom from Codehaus (which incidentally has a very interesting history of Apache and Phoenix), it is still the basis of some big projects like the Apache James mail server. Other micro kernals? How about JBoss? There is a good blog article dicussing how JBoss has been based on a micro kernel for some time now. The idea is nothing new and in fact in their case, OSGi does not really go far enough that they could be solely based on it. Actually, doesn't the Java EE EJB specification let you…
GUI Performance Enhancement Strategies
Graphical User Interfaces (GUIs) tend to be event driven. A user performs an action and the GUI sends that event to any interested components through a Model-View-Controller mechanism. When the events being sent represent fine grained actions (for example a single field on a form changed, as opposed to coarse grained events like the form being submitted), the performance of the GUI can become an issue. Other examples of when performance of the GUI might become an issue are: when the model in the GUI is large, when the GUI needs to process the data a lot in preparation for displaying it (either client or server side), when the GUI is poorly implemented and duplicate listeners exist meaning that components are refreshed multiple times, unnecessarily. The following strategy has been used to help improve GUI performance. This list is ordered with the easiest / most important tasks (least effort, best improvement) at the top: ensure a clean MVC implementation, without duplicate listeners, add data caches, optimise caches (e.g. they hold more than one object graph), optimise refreshing of non-active elements. 1) Clean MVC Implementation First of all, read the MVC article on this blog. Then, using a profiler or debugger follow your controller as it fires model change events. Are any model listeners fired more than once for any reason? If they are, it is less than optimal and you need to first look for mistakes in the programming logic. If there really is a good reason that the event…
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…
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…
