I need to cover some of my “blog debts”. Just didn’t around to persist my other Jazoon notes.

On Thursday afternoon Terrence Barr one of Sun’s Java ME evangelists gave a talk on “Developing Java ME applications using Sun’s open source platforms”.
Said but true, what I mostly remember is Terrence’s rush through his slides. He mentioned in the beginning that it was gonna be tight (time-wise) as the sessions at Jazoon are 10 minutes shorter than at other conferences. Be it as it may, can’t I expect a speaker to prepare accordingly? After all he seemed to have noticed beforehand that time constraints are different. You can’t just take your standard PowerPoint slides and squeeze them into a much smaller time box. As a listener I felt being served luke-warm Java.
Hot was the topic, though. Open-source Java ME is appealing. As I’m a novice to the Java ME world I’ll have to dig deeper to see what it can do for me. http://www.mobileandembedded.org will see me soon!
As a share holder of a major provider of commercial Java implementations for mobile devices I’m also eagerly following the market share of Sun’s open-source alternative…

Later that afternoon Simon Hefti, managing director of Zurich-based Netcetera AG, gave us an insight into what he calls “artificial complexity build-up”. He started with wonderful analogy for the problem:
Assume you bring in your car for maintenance. A few days later you’ll find yourself looking at a horribly high invoice although only a minor part in the engine had to be exchanged. However, since the faulty component was buried so deep down in the engine it had to be taken apart completely.
Artificial complexity imposes extra constraints on a problem solving process as it does not allow you to proceed straight forward. The problem itself may be easy to solve, but the context in which it lives makes it difficult. One key issue here is that weakening separation of concerns increases artificial complexity. This is true not just for the software industry. Simon talked a great deal about choices we make in terms of (third-party) components we bring into a software project. One might call this artificial complexity, of course; however, one might just as well speak of dependencies that complicate matters – something every developer will agree upon.
For a given set of desired functionality component A might cover 75%, component B another 20% while overlapping with what A does in certain areas. This still leaves you with 5% missing features although you’ve already introduced two external dependencies. Nonetheless, sometimes the bad boys are inside i.e. your own code. Simon cited from a study that showed that in more than 50% of cases where developers tried to anticipate future requirements and prepared accordingly (e.g. over-engineered or overly flexible APIs and thus increasing complexity) they were wrong.
Of course, there’s no generic solution to that, but raising awareness certainly helps. KISS!