Saturday, July 26, 2008

Reusability Revisited

Reading an article just now, something sparked off a thought process. I remember talking my manager years ago about things in general and he came out with something like 'object technology never lived up to its promise of reuse'.

Apart from the fact that I disagree that object technology has anything to do with the reuse argument, his comments about reuse were (and still are) a sore point with some folk. Reuse has long since been a holy grail of software development. We long to be able to plug together components like those clever electronics engineering types do, so that we can drastically reduce the time it takes to build software.

To attempt to achieve reuse take time and investment, something most projects cannot afford. On every project I have worked, there was a targeted deliverable and on those where the IT staff lost sight of this, the results were disastrous. But even if the project was will to spend the extra time and money investing in an attempt to build reusable parts, what is the return on investment? I have no doubt it can be made to work - but when I have seen this, there has always been a price to pay - code is very often in worse shape after refactoring changes required to make it work in a second context.

So, even if we could (i.e. we have the funding and the commitment from the project) should we do it? There are only two scenarios here I can think of -
1. We build something to fulfill an expected need and try to design for all occasions
2. We build something that fulfills the needs of a real product and try to adapt it to other solutions

The problems with 1 are that we're in an endless assumption mode, we don't know when we're done because we have no sound business reason for building something and its impossible to foresee what real projects actually will need. While I favor item two because its grounded on reality and emerging needs, it's still often impossible to reuse that part on another project. The more coarse grained the component the hard it will be to reuse it - because business rules are always different across projects.

This brings me to the next point I believe that level of abstraction is key to reuse. If we build some software to manipulate lists, it is much more likely that we can reuse it than if we build a class to calculate commission for a salesman. Why should this be? There are basic building blocks in life that can be use no matter what. Bricks and mortar and other building materials can be used to build a large array of different structures, but a house or a kitchen cannot be used to build a shopping mall. The closer to a business domain software gets, the more specific to that particular solution the code becomes, because most people in business actually want to do things differently to their competitors - in the belief that they can gain advantage by doing so.

Reuse takes many forms. Software especially libraries and fine grained (typically technology oriented) APIs, tooling and platforms and skills. The single most import item from which reuse can be gained, is the brain, knowledge and learning should be foremost and everything else will fall into place.

Thursday, July 10, 2008

TDD and User Interfaces Revisited

In my original post on the subject I considered the role of TDD in user interface development. There is an interesting post by Dean Wampler that also considers the subject and its interesting to get his perspective. The best thing to do when not sure about something in this business is to think for yourself - keep an open mind. Dean postulates that one should consider what to test and what NOT to test when test driving UIs. I would be interested to hear what Uncle Bob thinks about this, and whether it fits with his strong views on TDD, but I feel that much UI development should be left as nimble as possible - in fact some UI could be considered throw away - yet still built to production quality - but very easily changeable.

While business rules can and do change, the user presentation should be able to change with a quick click of the mouse in front of the customer. In fact, why not be able to have multiple flavors of UI, for different types of user/customer? I know this will be somewhat provocative, but I just don't see the practicality of test driving everything in the presentation layer. Of course, I still believe in automated acceptance testing - and this can still be test driven - just perhaps removing the emphasis on unit. What is a UI unit anyway?

I am playing devils advocate a little here, but it would be interesting to hear more opinions.

Erlang and the Object Oriented Viewpoint

In a blog post some time ago, Robert's post pointed me to
Ralphs Johnson article talking about the object oriented properties of Erlang.

This really intrigues me as I am a big (in every sense) OO fan. Getting a little more serious about learning Erlang recently, I am thinking more about the points Ralph put forward. Traditional OO thinking states that a language is object oriented if it supports inheritance, encapsulation and polymorphism. However, I don't know where this originated, or from whom. Is it supposed to be taken literally or is there a wide berth for interpretation of this loose definition. Message passing is also a central tenet which is generally overlooked by many supposed OO languages (Java, C++) preferring other mechanisms to achieve similar results, which I feel somewhat miss the point.

So, you cannot write an Erlang process that 'derives' from another process - but does that even matter? As Robert once said to me, the power of the OO paradigm is delegation, not inheritance, and that is something most people don't get. I also feel that OO systems help me to understand how things work and hence translate from the real world to that of computers. Encapsulation and message passing are easy to achieve and I could argue that polymorphism is possible - what about inheritance?

I really like the way message selection works with pattern matching and the total reliance on recursion, matching and higher order functions to eliminate need for many control constructs such as conditions or iterations. This is central to the incredible alleged reliability for the language.

Sunday, July 6, 2008

Actor and Object Models

Please bear with my ignorance with concurrency models, but I am very new to this. So, I am just reading up on the actor model, which I believe both Erlang and Scala are based on. According to Wikipedia --

"The Actor model adopts the philosophy that everything is an actor. This is similar to the everything is an object philosophy used by some object-oriented programming languages, but differs in that object-oriented software is typically executed sequentially, while the Actor model is inherently concurrent."

I did not think that there was any such limitation of the object model paradigm.

Is this correct?

Scala/Erlang Differences

I recently read this article at infoq and wondered if anyone could shed any more light on the debate?

Having looked at Erlang for a while, it seems like a refreshing approach to the accelerating needs for concurrency, but I confess to neither being confident with Erlang, nor having done much research as yet with Scala. I am not convinced that the fact that Scala is built on the JVM is actually an advantage, but it is a differentiator. Perhaps it will just be a case of paying your money and making a choice.