'. '

InfoQReview

From APIDesign

(Difference between revisions)
Jump to: navigation, search
Current revision (08:58, 4 April 2018) (edit) (undo)
(On Architects' Role)
 
(23 intermediate revisions not shown.)
Line 1: Line 1:
 +
== On Motivation ==
 +
: ''What was the motivation behind writing the "Practical API Design" book?''
: ''What was the motivation behind writing the "Practical API Design" book?''
-
This book is based on notes that I have collected over the last ten years,
+
The book is based on the notes I've been collecting over the past ten years
-
while designing and maintaining NetBeans APIs and transferring this knowledge
+
while designing and maintaining the NetBeans APIs. Also, they're based on
-
to the rest of our developers. I started to think about converting my notes
+
the process of transferring the NetBeans API knowledge
-
into a book five years ago, but it took long time before I really started.
+
to the rest of the NetBeans development team. I started to think about converting my notes
-
Either I had other tasks to do, or I was afraid of not being able to finish
+
into a book about five years ago. However, it took a bit of time before I really got started.
-
such book, afraid of being refused by publisher, etc.
+
At various points, other tasks got in the way. Other times I was simply afraid of not being able to finish
 +
the book, as well as the fear of being rejected by publishers, etc.
-
However in summer 2007, at one family garden party, I met my wife's cousin and
+
However, in the summer of 2007, I chatted to my wife's cousin at a family party.
-
when I told him about my doubts, he said: "So you know what to write about,
+
When I told him of my doubts, he said: "You know what to write about;
-
you know that it is an interesting topic, you know that you are an expert in
+
you know it is an interesting topic; you know you are an expert in
-
it, and you are still not writing!?".
+
it. So... why haven't you started writing yet?".
-
I always reminded his comment whenever my motivation to finish the "Practical
+
I was always reminded of this comment whenever my motivation to finish the "Practical
-
API Design" book weakened.
+
API Design" book flagged, which was to be expected in this kind of long running project.
-
PS: I'd like to thank everyone who helped me finish my book:
+
By the way, let me take this opportunity to thank everyone again who helped me finish my book:
http://thanks.apidesign.org/
http://thanks.apidesign.org/
 +
 +
== On DI, AOP and Annotations ==
: ''You discussed the Component Injection technique to achieve a ''
: ''You discussed the Component Injection technique to achieve a ''
Line 24: Line 29:
: ''software development in general and API design in particular? ''
: ''software development in general and API design in particular? ''
-
I believe that modularizing our applications into pieces is very desirable. It is even better if the pieces are unaware of each other and there is someone who assembles them together. To allow such assembly of loosely coupled pieces one desperately needs some form of injection. DI in the Spring style is fine. java.util.ServicesLookup works as well. I dedicated Chapter 7 to compare those and other alternatives.
+
I believe that modularizing applications into distinct parts is highly desirable. It's even better when those pieces aren't aware of each other, so that someone can assemble an application from the various independent parts. To allow this kind of assembly from loosely coupled pieces, it is essential to have some form of injection. Dependency injection in the Spring style is fine. java.util.ServiceLoader works as well. I dedicated chapter 7 of my book to a comparison of those and other alternatives.
-
There used to be time when people went nuts when they heard about bytecode manipulations. This is no longer true, people are not afraid to execute different bytecode than the one produced by Java compiler, yet if you tell them to go directly into the .class file and manipulate the bits the fear will be back. Why is that? I believe this is due to AOP. In fact AOP can be seen as a highlevel language for bytecode manipulations. It is not that power as if change the .class file directly, yet it is approachable to masses and generally understandable. I guess it is a perfect example showing that good abstractions make everything more usable. This is true in the world of bytecode manipulations as well as in API design.
+
There used to be a time when people went nuts on hearing the phrase "bytecode manipulation". That's no longer the case. People aren't afraid to execute bytecode different to that produced by the Java compiler anymore. However, if you tell them to go directly into the .class file and manipulate the bits, the fear returns. Why is that? I believe this is due to AOP. AOP make bytecode changes normal, without requiring understanding of the class file format. In fact, AOP can be seen as a high level language for bytecode manipulation. It is not as powerful as making changes to the .class file directly, yet it is approachable to the masses and generally understandable. This perfectly illustrates the principle that good abstractions make everything more usable. The principle is true in the world of bytecode manipulation as well as in that of API design.
-
We started to use annotations during recent version of NetBeans heavily. Basically we are defining new annotations as a facade over our old XML based API. During compilation, the annotations are processed by our annotation processors and the correct (old and complex) XML is generated. I cannot describe how satisfied we are. APIs are suddenly nicer, registrations are part of the Java source code, code completion works in IDEs automatically and all registrations are verified for correctness during compilation. I can only recommend compile time annotation for all API designers!
+
We started making heavy use of annotations during the development of the next version of NetBeans IDE. Basically, we are defining new annotations as a facade over our old XML-based API. During compilation the annotations are processed by our annotation processors. At the end of the processing, the correct (old and complex) XML is generated. I cannot begin to describe how happy we are with this solution! Our APIs are suddenly nicer. Registration information is now part of the Java source code. Code completion automatically works in IDEs. All registrations are verified for correctness during compilation. Based on these experiences, I can only recommend compile-time annotation to all API designers!
 +
 
 +
== On Quality ==
: ''You wrote ''
: ''You wrote ''
Line 35: Line 42:
: ''of the quality of software being written? ''
: ''of the quality of software being written? ''
-
There is a common wisdom among programmers saying that design cannot be done
+
Common wisdom among programmers is that design cannot be done
-
by committee. However how can we design bigger and bigger systems without
+
by committee. However, how can we design systems of increasing size without
-
designing in teams? Does not that hurt consistency? Yes, partially. Most
+
designing in teams? Doesn't working in a team hurt consistency? Yes, partly. Most
people seem to be able to keep design consistency when they work alone,
people seem to be able to keep design consistency when they work alone,
-
however software projects of today and of the future are designed by teams.
+
although software projects of today and of the future are designed in teams.
-
Keeping consistency in such environment is much harder, but it is possible.
+
Keeping consistency in such environments is much harder, but is certainly possible.
-
As usually, one has two choices: either detect regressions in quality when
+
As usual, one has two choices: either detect regressions in quality when
-
they happen, or prevent such problems before they are integrated. I have
+
they happen or prevent such problems from occurring before they are integrated. I have
-
dedicated full Chapter 16 to this topics. It describes what aspects need to
+
dedicated the complete chapter 16 to these topics. There I describe what aspects need to
-
be verified and checked, and how to check them automatically. This can warn
+
be verified and checked and how to check them automatically. In this way, we can be prepared for
-
us when something goes bad. Also it introduces an "API Review" process which
+
when things start going bad. Also, the chapter introduces an "API Review" process, which
-
the NetBeans team is using to do review API changes before integration.
+
the NetBeans team is following to review API changes before integration. This way we can prevent things to even think about regressing.
-
: ''How can Agile and lean ''
+
== On Relationship with [[Agile|Agility]] ==
-
: ''software development methodologies like SCRUM, XP and Kanban help a project''
+
-
: ''team involved in the design and development of API frameworks? ''
+
-
The question is whether agile methodologies help design and development of API
+
{{:Agile}}
-
frameworks, or whether properly modularizing an application and splitting it
+
-
into many libraries with APIs makes use of agile methodologies easier? Both
+
-
is likely true.
+
-
There are some good rules in the world of API design. You need to be ready
+
== On API Reviews ==
-
that first version is never perfect. You need to envision your users. Unit
+
-
test coverage is almost a must. One should be ready for evolution.
+
-
 
+
-
Many of the above advices are close to big rules of agile methodologies. As
+
-
such I think that proper API design and agile methodologies can only
+
-
strengthen together.
+
: ''Can you ''
: ''Can you ''
Line 70: Line 66:
: ''development project? ''
: ''development project? ''
-
We have two modes. Standard review and Fast-Track review. The latter one is
+
We have two modes: the standard review and the fast-track review. The latter is
-
used for small, incremental, compatible, non-controversial changes. It is
+
used for small, incremental, compatible, and non-controversial changes. It is
-
based on "optimistic locking strategy": one prepares the code change diff and
+
based on the "optimistic locking strategy": you prepare the code change diff and
-
attaches it to our issue tracking system. People then have a week to comment
+
attach it to the issue tracking system. People then have a week to comment
-
or veto the change. If nobody objects, it can be applied then. This works
+
or veto the change. If nobody objects in that time frame, the change can immediately be applied. This works
-
well for single method or class extensions to already existing libraries.
+
well for single method changes or class extensions to already existing libraries.
-
The Standard review is more targeted to reviewing a whole new library or
+
The standard review is targeted at reviewing a whole new library or
-
subsystem. It is two round review. First of all we review the concept, and if
+
subsystem. It is a two-round review. Firstly, we review the concept. Then, if
-
accepted the result is then reviewed again before integration to main code
+
the concept is accepted, the result is reviewed again before integration into the main code
repository.
repository.
All the gory details are available at
All the gory details are available at
http://openide.netbeans.org/tutorial/reviews/
http://openide.netbeans.org/tutorial/reviews/
 +
 +
== On Gotchas ==
: ''What are the best practices and "gotchas" that ''
: ''What are the best practices and "gotchas" that ''
Line 89: Line 87:
: ''component libraries? ''
: ''component libraries? ''
-
It slightly hard to enumerate them all, it took me 400 pages in the Practical
+
It is difficult to enumerate them all... it took me 400 pages in the Practical
-
API Design book. But let's pick up something inspiring:
+
API Design book. :-) But let's pick up on something interesting: "What do you think
-
 
+
is encompassed by the letters API?" The names of classes? Probably. The names of
-
What do you think the term API includes? Names of classes? Probably. Names of
+
their fields or methods? Yes, if they are public or protected. But is that
-
their fields or methods? Indeed, if they are public or protected. Is that
+
all?
all?
-
No, it is not. Did you ever think about the files your application reads as an
+
No, it isn't. Did you ever think of the files your application reads as being an
-
API? About open sockets being an API? Environment variables? Localized
+
API? And aren't the open sockets also an API? What about the environment variables? And the localized
-
messages? Text output that it produces? This all can influence the behaviour
+
messages? How about the text output produced by your code? All these can influence
-
of your application/library and also can be observed externally. As such, it
+
the behavior of your application or library. They can also be observed
-
is some kind of API. It is important to realize that and keep that in mind.
+
and used externally. As such, it
 +
is therefore some kind of API. It is very important to realize that and to
 +
always keep it in mind.
 +
 
 +
== On Architects' Role ==
: ''What is the role of software architects in the ''
: ''What is the role of software architects in the ''
Line 106: Line 107:
Tough question. The general answer is to learn to offer what the market
Tough question. The general answer is to learn to offer what the market
-
desperately needs. But I suspect nobody is really sure what it 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 - e.g. situations when you find out that your product has too many
+
changes, that is, situations where you find that your product has too many
-
bugs, design problems that it is unfixable and it needs complete rewrite.
+
bugs and design problems, to the extent that it is unfixable, requiring a complete rewrite.
-
Finding this out takes some time, usually the evidence needs to grow over
+
Coming to this point takes a very long time, with the evidence usually needing to grow over
-
few releases, but there is a point of time in lifecycle of most of software
+
several releases. However, there is a point in the [[lifecycle]] of most software
-
projects when someone offers to perform "bigbang" change. This is usually
+
projects where someone offers to perform a [[Big Bang]] change. Initially, the offer is declined
-
refused at first, as everyone understands such rewrite will be painful and
+
because everyone understands the rewrite will be painful and
-
costly. Yet over next few releases, when the evidence strengthens, the team
+
costly. Yet, over the next releases, while the evidence mounts, the team
-
realizes there is no escape. At that time the whole project is stopped, an
+
realizes there is no escape. At that point, the whole project is stopped, an
-
incompatible rewrite of some subsystem is put in and then the rest of teams
+
incompatible rewrite of a subsystem is forced, and then the other teams
-
adopts to such change. In spite how realistic plans were, this usually takes
+
need to adapt to the change. In spite of how realistic the original plans were, this process usually takes
-
much longer and at the end we can have a new shiny product which is less
+
much longer than expected. And, in the end, we now have a shiny new product which is less
-
buggy but handles just about a half of the functionality of the old one.
+
buggy than before but handles only about half the functionality of the original.
-
Needs less to say that this is not effective at all.
+
Needless to say, this is not an effective process at all.
-
The Practical API Design book describes best practices to avoid need for
+
The Practical API Design book describes best practices to avoid the need for
-
such "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, backward compatible changes, always focusing on
+
advocates small, incremental, backwardly compatible changes, while always focusing on
-
future evolution. Such mode does not need distruptive "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 they 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 behaviours and explains how
+
discusses ways to provide alternative co-existent behaviors and explains how
-
to bridge them together, if 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 may be slightly
+
replace them with continuous distributed improvements. This is maybe slightly
-
more expensive at first, but in the long term cost of ownership is definitely
+
more expensive at first, but the long term cost of ownership is definitely
lower.
lower.
-
All that said leads to following answer to your original question. Maybe
+
All that said, leads to the following answer to your original question: "Maybe
software architects should learn more about proper API design and use it to
software architects should learn more about proper API design and use it to
-
create more cost effective product teams.
+
create more cost effective product teams."
 +
 
 +
== On Java7 ==
: ''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.
-
Recently I was arguing with a Ruby guy about benefits of API design in Ruby.
+
Recently I argued with a Ruby guy about the benefits of API design in Ruby.
-
Originally it looked like "duck typing" is the big advantage, but then we
+
Originally, it seemed that "duck typing" is Ruby's big advantage. Then we
-
found out that real advantage is that Ruby has gems with all the library
+
agreed that Ruby's real advantage is all its "gems" with all their library
-
dependencies and Java has nothing. This needs to be fixed.
+
dependencies... while Java has nothing. This needs to be fixed.
-
I know there are existing module systems. Btw. one of them runs behind
+
I know there are existing module systems. By the way, one of these runs underneath
-
NetBeans, but by no means each library in the world is designed with
+
NetBeans IDE. However, by no means every library in the world is designed with
-
modularity in mind. This has 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 am even willing to wait next 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 the Java now.
+
years for [[closures]], if I can get the modularity in Java right now.
 +
 
 +
== On Favorite Language Feature ==
: ''If you have to pick a feature that you like the most in ''
: ''If you have to pick a feature that you like the most in ''
: ''Java language, what would it be? And the feature that you least like about?''
: ''Java language, what would it be? And the feature that you least like about?''
-
Java is said to have many weaknesses. However I guess one of its weaknesses is
+
Java is said to have many weaknesses. However, I guess one of its weaknesses is
-
also its biggest strength.
+
also its biggest strength: Java is said to be verbose. True, you can write
 +
shorter programs doing the
 +
same thing in many other languages. So, Java is verbose. However, the benefit of verbosity is that
 +
people are also able to read what they've written. Java programs can be
 +
read and understood by maintainers of its code. Moreover, this can be done on a printed page, without
 +
needing "go to declaration" functionality and the "code completion" feature of your an IDE.
 +
I guess I'm not really satisfied with Java's verbosity, however I do appreciate
 +
the readability that flows from it.
-
Java is said to be verbose. True, you can write shorter programs doing the
+
== On Favorite Book ==
-
same in many other languages. So Java is verbose. However the benefit is that
+
-
people can not only write the program, but also read it. Java programs can be
+
-
read and understood. Moreover this can be done on a printed page, without "go
+
-
declaration" and "code completion" in an IDE.
+
-
 
+
-
I guess I am not satisfied how verbose Java is. But I am really glad that it
+
-
is readable.
+
: ''Lastly, other than your own book, do you have an IT and a non-IT book''
: ''Lastly, other than your own book, do you have an IT and a non-IT book''
: ''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.
 +
 +
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.

Current revision

Contents

On Motivation

What was the motivation behind writing the "Practical API Design" book?

The book is based on the notes I've been collecting over the past ten years while designing and maintaining the NetBeans APIs. Also, they're based on the process of transferring the NetBeans API knowledge to the rest of the NetBeans development team. I started to think about converting my notes into a book about five years ago. However, it took a bit of time before I really got started. At various points, other tasks got in the way. Other times I was simply afraid of not being able to finish the book, as well as the fear of being rejected by publishers, etc.

However, in the summer of 2007, I chatted to my wife's cousin at a family party. When I told him of my doubts, he said: "You know what to write about; you know it is an interesting topic; you know you are an expert in it. So... why haven't you started writing yet?".

I was always reminded of this comment whenever my motivation to finish the "Practical API Design" book flagged, which was to be expected in this kind of long running project.

By the way, let me take this opportunity to thank everyone again who helped me finish my book: http://thanks.apidesign.org/

On DI, AOP and Annotations

You discussed the Component Injection technique to achieve a
Modular Architecture. What role design concepts like Dependency Injection
(DI), Aspect-Oriented Programming (AOP), and Annotations can play in
software development in general and API design in particular?

I believe that modularizing applications into distinct parts is highly desirable. It's even better when those pieces aren't aware of each other, so that someone can assemble an application from the various independent parts. To allow this kind of assembly from loosely coupled pieces, it is essential to have some form of injection. Dependency injection in the Spring style is fine. java.util.ServiceLoader works as well. I dedicated chapter 7 of my book to a comparison of those and other alternatives.

There used to be a time when people went nuts on hearing the phrase "bytecode manipulation". That's no longer the case. People aren't afraid to execute bytecode different to that produced by the Java compiler anymore. However, if you tell them to go directly into the .class file and manipulate the bits, the fear returns. Why is that? I believe this is due to AOP. AOP make bytecode changes normal, without requiring understanding of the class file format. In fact, AOP can be seen as a high level language for bytecode manipulation. It is not as powerful as making changes to the .class file directly, yet it is approachable to the masses and generally understandable. This perfectly illustrates the principle that good abstractions make everything more usable. The principle is true in the world of bytecode manipulation as well as in that of API design.

We started making heavy use of annotations during the development of the next version of NetBeans IDE. Basically, we are defining new annotations as a facade over our old XML-based API. During compilation the annotations are processed by our annotation processors. At the end of the processing, the correct (old and complex) XML is generated. I cannot begin to describe how happy we are with this solution! Our APIs are suddenly nicer. Registration information is now part of the Java source code. Code completion automatically works in IDEs. All registrations are verified for correctness during compilation. Based on these experiences, I can only recommend compile-time annotation to all API designers!

On Quality

You wrote
in the book about how to check the quality of an API library. Can you
elaborate on how the teams can have an on-going assessment and validation
of the quality of software being written?

Common wisdom among programmers is that design cannot be done by committee. However, how can we design systems of increasing size without designing in teams? Doesn't working in a team hurt consistency? Yes, partly. Most people seem to be able to keep design consistency when they work alone, although software projects of today and of the future are designed in teams. Keeping consistency in such environments is much harder, but is certainly possible.

As usual, one has two choices: either detect regressions in quality when they happen or prevent such problems from occurring before they are integrated. I have dedicated the complete chapter 16 to these topics. There I describe what aspects need to be verified and checked and how to check them automatically. In this way, we can be prepared for when things start going bad. Also, the chapter introduces an "API Review" process, which 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

How can Agile and lean
software development methodologies like SCRUM, XP and Kanban help a project
team involved in the design and development of API frameworks?

The question is whether agile methodologies help design and development of API frameworks... or whether properly modularizing an application and splitting it into many libraries with APIs simplifies the use of agile methodologies? Both are probably true.

There are several sound rules in the world of API design. For example, you need to be aware at the outset that the first version of your API is not going to be perfect. Also, you need to envision who your users are. Two other basic principles are that unit test coverage is almost a must and that you should always design your API in such a way that it is ready to be evolved further.

Many of these pieces of advice are close to being the governing rules of agile methodologies as well. As such, I think that proper API design and agile methodologies can only strengthen each other.

On API Reviews

Can you
discuss how your team conducted architecture and design reviews in NetBeans
development project?

We have two modes: the standard review and the fast-track review. The latter is used for small, incremental, compatible, and non-controversial changes. It is based on the "optimistic locking strategy": you prepare the code change diff and attach it to the issue tracking system. People then have a week to comment or veto the change. If nobody objects in that time frame, the change can immediately be applied. This works well for single method changes or class extensions to already existing libraries.

The standard review is targeted at reviewing a whole new library or subsystem. It is a two-round review. Firstly, we review the concept. Then, if the concept is accepted, the result is reviewed again before integration into the main code repository.

All the gory details are available at http://openide.netbeans.org/tutorial/reviews/

On Gotchas

What are the best practices and "gotchas" that
software architects should keep in mind when working on creating reusable
component libraries?

It is difficult to enumerate them all... it took me 400 pages in the Practical API Design book. :-) But let's pick up on something interesting: "What do you think is encompassed by the letters API?" The names of classes? Probably. The names of their fields or methods? Yes, if they are public or protected. But is that all?

No, it isn't. Did you ever think of the files your application reads as being an API? And aren't the open sockets also an API? What about the environment variables? And the localized messages? How about the text output produced by your code? All these can influence the behavior of your application or library. They can also be observed and used externally. As such, it is therefore some kind of API. It is very important to realize that and to always keep it in mind.

On Architects' Role

What is the role of software architects in the
current economic and market conditions?

Tough question. The general answer is to learn to offer what the market needs. But I suspect nobody is really sure what that is. Except...

...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 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 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 because everyone understands the rewrite will be painful and costly. Yet, over the next releases, while the evidence mounts, the team realizes there is no escape. At that point, the whole project is stopped, an incompatible rewrite of a subsystem is forced, and then the other teams need to adapt to the change. In spite of how realistic the original plans were, this process usually takes much longer than expected. And, in the end, we now have a shiny new product which is less buggy than before but handles only about half the functionality of the original. Needless to say, this is not an effective process at all.

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 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 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 to bridge them, when necessary.

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 replace them with continuous distributed improvements. This is maybe slightly more expensive at first, but the long term cost of ownership is definitely lower.

All that said, leads to the following answer to your original question: "Maybe software architects should learn more about proper API design and use it to create more cost effective product teams."

On Java7

What do you think about the new
features and APIs in the upcoming JDK Version 7 and the dropped features
like Closures?

The #1 thing that Java needs is a standard module system adopted by everyone. Recently I argued with a Ruby guy about the benefits of API design in Ruby. Originally, it seemed that "duck typing" is Ruby's big advantage. Then we agreed that Ruby's real advantage is all its "gems" with all their library dependencies... while Java has nothing. This needs to be fixed.

I know there are existing module systems. By the way, one of these runs underneath NetBeans IDE. However, by no means every library in the world is designed with 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 years for closures, if I can get the modularity in Java right now.

On Favorite Language Feature

If you have to pick a feature that you like the most in
Java language, what would it be? And the feature that you least like about?

Java is said to have many weaknesses. However, I guess one of its weaknesses is also its biggest strength: Java is said to be verbose. True, you can write shorter programs doing the same thing in many other languages. So, Java is verbose. However, the benefit of verbosity is that people are also able to read what they've written. Java programs can be read and understood by maintainers of its code. Moreover, this can be done on a printed page, without needing "go to declaration" functionality and the "code completion" feature of your an IDE. I guess I'm not really satisfied with Java's verbosity, however I do appreciate the readability that flows from it.

On Favorite Book

Lastly, other than your own book, do you have an IT and a non-IT book
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.

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.

Personal tools
buy