Sun's Joshua Bloch On OOP/OOD In Java

f00zbll writes: "A good article about development and OOP/OOD. The lessons apply to most OO languages and OOD. Interview with Joshua Bloch over at Javaworld. Ignore the fact that Java is owned by Sun and use the tips to help your work/project/development."

Comments

Business vs Academic

[wayn3]

The trouble with these kinds of interviews is that although I appreciate and enjoy Mr. Bloch's contributions to Java and Mr. Venners' forum, they are speaking academicly and not through the world of business. This is a very narrowly focused article and should not be taken as direction for designing software.

I'd like to hear someone write about how to make the trade-offs architects really face:

• being forced to use lesser software products and tools due to cost or partnership arrangements;
• having time-to-market be a larger issue than software reuse
• attempting design and development when the skill set is diverse

These topics would be of greater value to the development community than articles which presume hypothetical arrangements.

Re:Business vs Academic

[jilles]

Time to market these days means being able to reuse and adapt the previous product's software as quickly as possible. A good design is essential for that and companies that don't do good design are outcompeted by companies who manage to produce better quality software in a shorter timeframe.

The reality of today is that software systems are very large (think millions of lines of code) that represent an investment of many manyears. A quick fix on such code can have a desastrous impact on the time to market of future products. I know of companies that effectively did not bring out new products for two years because they were busy redesigning their software in order to be able to meet future requirements(Netscape is a good example in the public domain).

One of the reasons Java is currently so successful and has seen a quicker time to market than .Net (which has yet to come to market) is good design. Sun spent a great deal of time thinking about security and flexibility as early as 1995. This investment has allowed Java to mature well before MS managed to get anything significant to market. SUN is actively working with industry partners in its much criticized JCP process. MS on the other hand is dictating standards. MS gets its standards out quicker but the ones that get through the JCP process are of such a quality that they are causing MS some very big headaches in for example the mobile applications domain.

I am from the academic world and (pretty rare for an acadamic) I frequently visit software developing companies to gather information for my research. The more successful of these companies invariably have very clever software designers in charge of the software development. Also these companies are very much aware that the quality of their software is their competitive edge.

Re:Business vs Academic

[f00zbll]

Perhaps a good related article would be, "how to negotiate with your PM or CTO." Even if one is forced to use lesser tools, some of tips do apply. One in particular was:

They do advocate leaving out the bells, whistles, and features you don't need and add them later, if a real need is demonstrated. And that's incredibly important, because you can always add a feature, but you can never take it out. Once a feature is there, you can't say, sorry, we screwed up, we want to take it out because other code now depends on it. People will scream. So, when in doubt, leave it out.

I know that sometimes I am tempted to add x feature to the interface/code, because I think in 2 months the need for it will arise. Sometimes what I predict doesn't pan out. The lessons Joshua relates is very applicable in every day programming. Even if you use functional languages, the same challenges are there and the lessons can be beneficial. It's not always going to be useful, but it can be. It's up to each developer to make the effort. Sometimes you have no choice, but when you do have time, it's worth the trouble to take a minute to think a design/API through.

Re:Business vs Academic

[cpeterso]

In this way, software components are opposite to mechanical devices: the more they are used, the more reliable they become.


Also, a reliable machine is composed of many duplicate, individually tested components. A well-factored software system does not contain any (or much) redudant or duplicate code!

Re:Fights with managers

[Twylite]

The fact that you aren't prepared to stand up to your manager is the first sign of a problem. You have to make management understand that you are (I assume) a professional. Development or (hopefully) software engineering is your career, for which you are educated, and that in such areas management does NOT have the required knowledge to act.

In no other technical profession can management dictate HOW the job should be achieved. They can set budgets and deadlines, and assist in planning, but they do not have the liberty to force a domain expert to act in a certain way.

This needs to be made more clear to software managers. Software is difficult to write and to maintain. Even though most contracts seem watertight, there is an element of liability implicit in the sale of custom-developed software, which makes YOUR organisation responsible. And as the software engineer someone is going to shit on YOUR head when things go wrong ... not the manager's.