When Software is broken…

Software Engineering

You get something like this:

Nachträgliche manuelle Umbuchungen sind technisch völlig ausgeschlossen, da ein zentrales Rechenzentrum mit Warenwirtschaftssystemanbindung sämtliche Buchungsvorgänge vollautomatisch steuert.

Or in English:

Manual modifications afterwards are technically absolutely impossible, because we have a central data center with ERP system integration which controls every booking totally automated.

Alternative translation:

We don’t have control over our software. Sorry folks, you lost.

I get this sentence whenever I want to make a change to an already place order. For example, an item is on backorder and it just takes too long but there is a similar one available on stock. Actually I would expect the system to detect this before I place an order but that’s another story.

#onlineshop #eibmarkt #fail 🙁

Understanding Open Source

Eclipse, Software Engineering, ,

I came across this couple of times before and I always wanted to blog about it. In my daily work life I see many developers which just don’t get Open Source. For example, some discover issues in libraries they use. But they don’t fix them. They don’t even inform the maintainers of a library. Yet others have a great new use-case to address. Again, the library doesn’t support it. Thus, they write a great deal of new code to address their issue and eventually run into new ones (for example, see this thread).

But it’s that darn simple!

  1. Checkout the library from source. You can use a well known tag/branch for this.
  2. Get in touch with the maintainers and implement your modifications.
  3. Build and release your modified version until a new official release is available.

Eclipse must change!

Eclipse

I opened my RSS reader this morning and found a few more interestings posts from Bjorn, Doug and Micheal ind the Planet Eclipse feed. I really have to thank Bjorn for starting this  discussion. He raised some very good points. The posts I read also made me think more about it.

I do not agree with all the ideas. Well, I don’t have to. Especially I don’t like to see the Eclipse Foundation hiring Eclipse developers. But I have another idea. It’s not that of a big deal, i.e. we could tackle it today with the process we have in place. But it’s not a low hanging fruit either.

Think along the lines of the Runtime project. It’s a great project with a diverse committer community. I think we should archive the Eclipse project. Equinox already moved out. The desktop bits could move to the RT project as well. RAP is already there so SWT, JFace and parts of the workbench would be a good fit too. The IDE stuff, JDT, Help and Resources bits could move to the Tool project. e4 clearly is a Technology project. Why didn’t it start as such in the beginning? Is it all driven by the fear of one contributor?

I think you get the point. It’s not so important what we move where. I think it’s more important that we refactor the Eclipse project. It’s too large, too complex and too difficult for adopters to understand it and to get involved. We should listen to ourselves. It’s written in the Equinox whitepaper. I’d like to see more smaller components, which are developed and evolved independent from each other. That’s easier to handle and to develop than one large code base.