Sun's Joshua Bloch On OOP/OOD In Java 28
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."
Fights with managers (Score:2, Interesting)
This is one of the most common fights between us (developers) and management. Often managers are only interested on the fastest route, without considering the maintenance costs down the road.
I'll be emaling my manager a link to this story (anonimously, of course. I want to keep my job ;-)
John
Re:Fights with managers (Score:3, Insightful)
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.
Business vs Academic (Score:4, Insightful)
I'd like to hear someone write about how to make the trade-offs architects really face:
These topics would be of greater value to the development community than articles which presume hypothetical arrangements.
Re:Business vs Academic (Score:2, Interesting)
Did you read the same article I did? Designing robust APIs, decomposing modules and interfaces into simple and testable pieces, defensive programming are all hallmarks of high quality large-scale systems. Articles addressing your concerns have a place -- hey, maybe you could write one! -- but this article is clearly meant for a different audience.
Chris
Re:Business vs Academic (Score:4, Insightful)
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
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 (Score:2)
-
Less development time, because you're re-using code you have already written.
-
Less debugging time, because every defect you correct in a shared piece of code fixes several bugs.
In this way, software components are opposite to mechanical devices: the more they are used, the more reliable they become.Re:Business vs Academic (Score:2)
The days that you could start from scratch for a each new product are gone. Many companies are currently finding out the hard way that the cost of that is too much. Take Nokia for example. They produce around 30 or so different mobile phones each year. Each of these phones contains a few million lines of code in software. Obviously, Nokia does not start from scratch for each new phone. Rather they taylor and extend their previous generation software and use it in the next generation phone. The better the design of the old software the easier it is to add new features. Getting new features out a few months before the competitor is critical in the mobile phone industry (one of the reasons Ericsson is having so much trouble).
The type of blackboard reuse you are talking about is very hard to achieve. Basically COTS is a myth except for some generic GUI components and low level stuff like XML parsing. The problem is that creating a reusable component requires knowledge in advance of the requirements it needs to meet. Something every software developer knows is that unexpected requirements will pop up. Hence you will find yourself editing your carefully designed components after some time. Especially when you use your old components in a new product you will find that the requirements are different and that your components do not match 100% in the new situation.
This is why you need a good design: to limit the impact of these inevitable changes.
Re:Business vs Academic (Score:2, Insightful)
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!
Who wins the competition really? (Score:2)
Great theory. Unfortunately, you forgot that the company who does the quick but not reuseable work gets to market first. If they get there "first enough", the competition are already toast. All the reusability in the world doesn't mean jack if your company has already lost 95% market share to a rival who released 6 months earlier.
I am a great believer in the fact that "quality is free" -- doing a proper job of things like initial design and documentation more than pays for itself in the long run. However, it's important to do all things in moderation. Remember the old rule that it's only reuseable if it's useable in the first place. There is no point overengineering an initial solution for reuse if you're not going to meet your first set of requirements, which normally includes getting to market within a competitive timeframe. If an initial design isn't up to that, is it really a good design at all?
Well, that and a few years' headstart, anyway. :-)
Re:Business vs Academic (Score:2, Insightful)
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 (Score:2)
Re:Business vs Academic (Score:2)
how about a constraint called time-to-version-2.0? The real race happens then, when market expectations and wishes are more apparent.
Re:Time to market vs. reuse (Score:2)
Re:Business vs Academic (Score:1)
There's nothing inevitable about it at all. Designing and implementing reusable components takes time and if sufficient time is not available, the quality will suffer.
It's also true that a "good architect" (if we are talking about a real human being) will screw-up once in a while.
No choice of language, methodology, process, or personel will make a quality product inevitable. You have to fight that battle anew for each and every product.
The problem is there's not much to say (Score:2)
OK, what can you really say about these issues?
So you do the best with what you can, and it either works or it doesn't, and you make money or you don't, or you stay in business or go out of business.
If you want to talk about business reality, that's business reality. The dot com boom and the dot com bust are business reality. Incredible hype about Enron followed by its bankruptcy are business reality. The recession is business reality, and so is prosperity. And sometimes business reality is producing crap software that is full of holes.
You have your compromise already. You work like hell and design well and find out that for all that people in business talk about profit for the company, it all turns out to be the color of their parachute. Then you figure this out and either cheat like all the rest or else you get into a position where you are allowed to write good software, which is almost never software that is sold, unless it's a game or industrial control software. What other kind of compromise were you expecting?
You can do things properly, or you can do them improperly. When you do them improperly they fail more often. You can pile up good, solid business reasons why you have to do things improperly, and I don't care what color your power tie or how earnest and "forward-looking" you are, or how many inspirational posters you have, doing things improperly leads to failure.
Any veteran of business software development would know these things and, if honest, would have to write about them. Then people wouldn't like it, and they'd mod it down or not buy the book or tell the author he's an asshole because they want to hear that there's a magic incantation that turns mediocrity into gold. They want to hear about Extreme Programming or The Latest New Buzzword that Embraces Change! The newer the better. Old ideas are annoying, because you've already had time to find out that they don't magically work, while there's always the chance that the latest and greatest will make everything OK and nobody will have to get nailed to a tree.
Re:Business vs Academic (Score:1)
I have no idea why you say this is academic. You may have heard of Josh Bloch's company, the one he is paid to write APIs for. It's called Sun. Sun are very serious about business and not about being academics.
I consider Josh Bloch's book on Java (Effective Java) to be the best language-specific book on architecture and software engineering I have read. The format is based on Meyer's highly acclaimed Effective C++. Venner's own books are clearly based heavily on his own decades of experience and yet he sees in Bloch's wisdom something which makes software work better for the programmers who have to continue to build it. Also, Gosling, Java's creator says Bloch's book is the only book on Java which he needs. Of course they both work for sun, but there are plenty of other useful books put out by Sun which he could have acclaimed.
Incidently your point is well taken about the sorts of topics you would like to read about. Those topics are linked directly off Venner's site [artima.com] because he writes about them all the time, including in Java World. Venner's article talks about the monkeys on the back of the software developer. The Biggest monkey is the time-to-market deadline moneky.
In my view, time to market is important, but it can't possibly be more important than the fact that when you get to the market, you'd better have something worth selling.
Re:Business vs Academic (Score:1)
OK, in order:
Creating code that can't be reused in similar contexts is like filing down a block of metal every time you need a screwdriver. It's silly. Good code is like a craftsman's favorite set of tools, it can be used in many ways to make customers happy. The recommendations of Mr. Bloch expose how experts in the craft of software construction think about and do their work.
Auhhh :-) (Score:3, Interesting)
As a
developed this API design philosphy on my own.
Actually, I have evolved to it.
If you are in a one-mans shop, or do alot of coding
for a specific domain, try to roll out your own
layer of helper APIs on top of the system provided ones.
I work on win32 and ODBC: I have my own class
hierchies of *standard* dialogs for DB applications.
Ex: the ActiveX components for DB Appz (advanced
list views, financial stats, bar charts and graphs, etc.)
are really resource greedy (the updating required
for a dynaset database connection, with millions
of records being fetched per minute is very
expensive.)
So I wrote some ready to run classes, that take
care of the interface (with all the company logos
and standard look-and-feel stuff.)
then wrote some other classes to wrap around the
"CResultView" classes, and finally,
wrote some classes that *know* about our strange
servers, and are optimized for them (including
a connection "language" I derived, which is nothing
more than a hand optimization of the subset of
SQL accepted by oracle.)
So, if the shop is good to you, be good to them
and put your talent to work.
The API method works, and I am a living witness for it.
Rest of interview available... (Score:2)
Topics include how much subclasses should be "trusted", immutables, reasons for disallowing inheritance, copy v. cloning, factory methods versus constructors, and more.