Mostrando postagens com marcador architecture. Mostrar todas as postagens
Mostrando postagens com marcador architecture. Mostrar todas as postagens

quarta-feira, 9 de setembro de 2009

Horror plot in software development!

There are few things in this world that is worth to do over and over again, but I am but that falling in the same stupid errors is not one of them. I have just left a meeting where, for my surprise, people are happy to do it again.
I will put it as example: let's imagine that you have a car factory, your car is not the best in the world, but some people like it. Then you realize that every time that your customer wants a new item into the car (like ABS, radio, etc) you should almost rebuild the car.
After years one of your engineers come up with the brilliant idea: let's build a car that the user can choose what we wants at fly, so if he wants a radio he just tell us and suddenly the radio is there. Uou marvelous isn't it?
Then some more years to develop it, and you finally have the car! But as car stuffs increase people start to say: "you know, let's not make it configurable, it gives us a lot of problem". Sooooo guess what: you end up with the same car as before.
As I told you: the same mistake.

It is like an horror history: doesn't matter how much times do you kill Jason, he will always come back, there will be a lot of blood, a lot of people will died in the way, eventually we could have a happy end (the guy get the girl and that is it); but still a lot of suffering.

The point is: doesn't matter the end, we are still writing horror histories, and there will be blood! We should before changing the players start to think about changing the kind of history, way not action? Or a comedy or a even romance? You know: light stuff!

Going back to our original example: the car was made in the same way, the same approach, way should the result should be different? No way, it will be the same!

About software (yeap it is a software blog): if we keep looking at your application in the same way, they will always look the same. And I am not talking about the technology that we use for that, but the way that we do that.
It should be configurable, let's make it in a way that I could be configurable, not just adding properties. It should be multi environment, let's do in a way that it could be deployed multi environment; and so on.

To finish: in the next article I will add my idea of how a specific kind of enterprise application should be done. Why this kind? In the last years I have faced this kind of application all around and no easy approach to it.

Now you ask me: what kind of application? Well I am writing this post in a thriller way, so you will see it in the next issue ;-)

domingo, 8 de junho de 2008

Naked Object Architecture

Probably you have already listened about Naked Objects. But do you know what they are?
Basically it is a architecture and a framework proposed/created by Richard Pawson, as a Phd thesis. It is based, more or less, on two concepts: OOUI (object oriented user interface) and Domain Objects.
The main idea behind them is: you develop the domain object (also know as business objects) and the framework will handle the user interface automatically. Them the users will work directly with the domain objects.
As all architectures it has pros and agains. As pro we can say that it has a fast time development, as again we can say that all business logic should be at the domain objects. In fact there is more pros and agains (these are just the first ones that you can notice).
Although many of you can say that is just for mickey mouse software, I don't agree. Let's face that some software are basically changes on domain objects, for example, those famous C.R.U.D. application, where usually we handle legacy data in the same way.
Why should we care about spending time developing and complete application? But remember that we must know how far this application is goint to, it could become a nightmare to maintain.

It is just a brief introduction to naked objects, I am still reading the articles and the thesis. If you want more information about that you could refer to these links (at least I am using them to learn more about it):
I think that is not necessary to tell it, but I will say it anyway: naked objects are not java or java related. It is a architecture and a framework and as it is it could be implemented in any language and it could be combined with any other architecture, like client-server, web, etc.