bugs and design problems, to the extent that it is unfixable, requiring a complete rewrite.

bugs and design problems, to the extent that it is unfixable, requiring a complete rewrite.

Coming to this point takes a very long time, with the evidence usually needing to grow over

Coming to this point takes a very long time, with the evidence usually needing to grow over

several releases. However, there is a point in the lifecycle of most software

several releases. However, there is a point in the [[lifecycle]] of most software

projects where someone offers to perform a [[Big Bang]] change. Initially, the offer is declined

projects where someone offers to perform a [[Big Bang]] change. Initially, the offer is declined

because everyone understands the rewrite will be painful and

because everyone understands the rewrite will be painful and

to bridge them, when necessary.

to bridge them, when necessary.

If we modularize our applications and treat each piece as a library with an

If we [[modularize]] our applications and treat each piece as a library with an

API, we can minimize the need for stop-the-world [[Big Bang]] rewrites and

API, we can minimize the need for stop-the-world [[Big Bang]] rewrites and

replace them with continuous distributed improvements. This is maybe slightly

replace them with continuous distributed improvements. This is maybe slightly

My book references Effective Java and the [[Gang of Four]]'s design pattern book. Those are a must read and indeed they are very well known already.

My book references Effective Java and the [[Gang of Four]]'s design pattern book. Those are a must read and indeed they are very well known already.

Beyond these, I also reference a perfect book by [[wikipedia::Petr_Vopenka|Petr Vopěnka]] about the history of geometry: "The Key Stone of European Knowledge". It may sound boring at first, but it isn't and I fell in love with it. Many of [[TheAPIBook|Practical API Design]]'s "philosophical" sections are based on ideas from that book. So, if you belong to the camp that finds those parts interesting, I'd recommend the book to your attention. There is just one problem... it hasn't been translated to English yet.

Beyond these, I also reference a perfect book by [[wikipedia::Petr_Vopenka|Petr Vopěnka]] about the history of geometry: "[[The Key Stone of European Knowledge]]". It may sound boring at first, but it isn't and I fell in love with it. Many of [[TheAPIBook|Practical API Design]]'s "philosophical" sections are based on ideas from that book. So, if you belong to the camp that finds those parts interesting, I'd recommend the book to your attention. There is just one problem... it hasn't been translated to English yet.

needs. But I suspect nobody is really sure what that is. Except...

needs. But I suspect nobody is really sure what that is. Except...

...one of the problems in software development is associated with "big bang"

...one of the problems in software development is associated with [[Big Bang]]

changes, that is, situations where you find that your product has too many

changes, that is, situations where you find that your product has too many

bugs and design problems, to the extent that it is unfixable, requiring a complete rewrite.

bugs and design problems, to the extent that it is unfixable, requiring a complete rewrite.

Coming to this point takes a very long time, with the evidence usually needing to grow over

Coming to this point takes a very long time, with the evidence usually needing to grow over

several releases. However, there is a point in the lifecycle of most software

several releases. However, there is a point in the lifecycle of most software

projects where someone offers to perform a "bigbang" change. Initially, the offer is declined

projects where someone offers to perform a [[Big Bang]] change. Initially, the offer is declined

because everyone understands the rewrite will be painful and

because everyone understands the rewrite will be painful and

costly. Yet, over the next releases, while the evidence mounts, the team

costly. Yet, over the next releases, while the evidence mounts, the team

The Practical API Design book describes best practices to avoid the need for

The Practical API Design book describes best practices to avoid the need for

these "big bang" changes. First of all it explains what compatibility is and

these [[Big Bang]] changes. First of all it explains what compatibility is and

advocates small, incremental, backwardly compatible changes, while always focusing on

advocates small, incremental, backwardly compatible changes, while always focusing on

future evolution. A mode of this kind does not need diruptive "big bang" changes at

future evolution. A mode of this kind does not need diruptive [[Big Bang]] changes at

all. On the other hand, sometimes such large changes are necessary. That is why the book

all. On the other hand, sometimes such large changes are necessary. That is why the book

discusses ways to provide alternative co-existent behaviors and explains how

discusses ways to provide alternative co-existent behaviors and explains how

If we modularize our applications and treat each piece as a library with an

If we modularize our applications and treat each piece as a library with an

API, we can minimize the need for stop-the-world "big bang" rewrites and

API, we can minimize the need for stop-the-world [[Big Bang]] rewrites and

replace them with continuous distributed improvements. This is maybe slightly

replace them with continuous distributed improvements. This is maybe slightly

more expensive at first, but the long term cost of ownership is definitely

more expensive at first, but the long term cost of ownership is definitely

My book references Effective Java and the [[Gang of Four]]'s design pattern book. Those are a must read and indeed they are very well known already.

My book references Effective Java and the [[Gang of Four]]'s design pattern book. Those are a must read and indeed they are very well known already.

Beyond these, I also reference a perfect book by Petr Vopěnka about the history of geometry: "The Key Stone of European Knowledge". It may sound boring at first, but it isn't and I fell in love with it. Many of Practical API Design's "philosophical" sections are based on ideas from that book. So, if you belong to the camp that finds those parts interesting, I'd recommend the book to your attention. There is just one problem... it hasn't been translated to English yet.

Beyond these, I also reference a perfect book by [[wikipedia::Petr_Vopenka|Petr Vopěnka]] about the history of geometry: "The Key Stone of European Knowledge". It may sound boring at first, but it isn't and I fell in love with it. Many of [[TheAPIBook|Practical API Design]]'s "philosophical" sections are based on ideas from that book. So, if you belong to the camp that finds those parts interesting, I'd recommend the book to your attention. There is just one problem... it hasn't been translated to English yet.

 

: ''recommendation for our readers?''

: ''recommendation for our readers?''

My book references Effective Java and the Gang of Four's design pattern book. Those are a must read and indeed they are very well known already.

My book references Effective Java and the [[Gang of Four]]'s design pattern book. Those are a must read and indeed they are very well known already.

Beyond these, I also reference a perfect book by Petr Vopěnka about the history of geometry: "The Key Stone of European Knowledge". It may sound boring at first, but it isn't and I fell in love with it. Many of Practical API Design's "philosophical" sections are based on ideas from that book. So, if you belong to the camp that finds those parts interesting, I'd recommend the book to your attention. There is just one problem... it hasn't been translated to English yet.

Beyond these, I also reference a perfect book by Petr Vopěnka about the history of geometry: "The Key Stone of European Knowledge". It may sound boring at first, but it isn't and I fell in love with it. Many of Practical API Design's "philosophical" sections are based on ideas from that book. So, if you belong to the camp that finds those parts interesting, I'd recommend the book to your attention. There is just one problem... it hasn't been translated to English yet.

http://en.wikipedia.org/wiki/Petr_Vopenka

http://en.wikipedia.org/wiki/Petr_Vopenka

: ''What do you think about the new ''

: ''What do you think about the new ''

: ''features and APIs in the upcoming JDK Version 7 and the dropped features''

: ''features and APIs in the upcoming JDK Version 7 and the dropped features''

: ''like Closures? ''

: ''like [[Closures]]? ''

The #1 thing that Java needs is a standard module system adopted by everyone.

The #1 thing that Java needs is a standard module system adopted by everyone.

modularity in mind. This has got to be changed. There needs to be support for

modularity in mind. This has got to be changed. There needs to be support for

modularity in the Java language itself. I'm even willing to wait a few

modularity in the Java language itself. I'm even willing to wait a few

years for closures, if I can get the modularity in Java right now.

years for [[closures]], if I can get the modularity in Java right now.

== On Favorite Language Feature ==

== On Favorite Language Feature ==

the NetBeans team is following to review API changes before integration. This way we can prevent things to even think about regressing.

the NetBeans team is following to review API changes before integration. This way we can prevent things to even think about regressing.

== On Relationship with Agility ==

== On Relationship with [[Agile|Agility]] ==

: ''How can Agile and lean ''

{{:Agile}}

 

 

 

== On API Reviews ==

== On API Reviews ==

: ''recommendation for our readers?''

: ''recommendation for our readers?''

My book references Effective Java and Gang of Four's design pattern book. Those are a must read and indeed they are well known.

My book references Effective Java and the Gang of Four's design pattern book. Those are a must read and indeed they are very well known already.

Beyond these I also reference a perfect book by Petr Vopěnka about history of geometry: "The Key Stone of European Knowledge". It may sound boring at first, but it is not and I fell in love with it. Many of Practical API Design's "philosophical" sections are based on ideas of that book. So if you belong to the camp that finds those parts interesting, I'd recommend the book to your attention. There is just one problem: It has not yet been translated to English.

Beyond these, I also reference a perfect book by Petr Vopěnka about the history of geometry: "The Key Stone of European Knowledge". It may sound boring at first, but it isn't and I fell in love with it. Many of Practical API Design's "philosophical" sections are based on ideas from that book. So, if you belong to the camp that finds those parts interesting, I'd recommend the book to your attention. There is just one problem... it hasn't been translated to English yet.

http://en.wikipedia.org/wiki/Petr_Vopenka

http://en.wikipedia.org/wiki/Petr_Vopenka

My book references Effective Java and Gang of Four's design pattern book. Those are a must read and indeed they are well known.

My book references Effective Java and Gang of Four's design pattern book. Those are a must read and indeed they are well known.

Beyond these I also reference a perfect book by Petr Vopěnka about history of geometry: "The Key Stone of European Knowledge". It may sound boring at first, but it is not and I felt in love with it. Many of Practical API Design's "philosophical" sections are based on ideas of that book. So if you belong to the camp that finds those parts interesting, I'd recommend the book to your attention. There is just one problem: It has not yet been translated to English.

Beyond these I also reference a perfect book by Petr Vopěnka about history of geometry: "The Key Stone of European Knowledge". It may sound boring at first, but it is not and I fell in love with it. Many of Practical API Design's "philosophical" sections are based on ideas of that book. So if you belong to the camp that finds those parts interesting, I'd recommend the book to your attention. There is just one problem: It has not yet been translated to English.

http://en.wikipedia.org/wiki/Petr_Vopenka

http://en.wikipedia.org/wiki/Petr_Vopenka