 |
Where are we going? (warning: rants ahead)
Posted by fabriziogiudici on January 08, 2007 at 03:38 AM | Comments (25)
I returned from JavaPolis with a bag of mixed feelings. The good ones: the conference was great, well organized, rich of contents (I'm repeating again, three days of conference for 200€ is excellent price for value), I met people, last but not least the idea of reaching Antwerp by car was very good as I enjoyed my photographic trip through northern France. The bad ones: I'm worried about where Java 7 is possibly going and about the topics that the community is possibly perceiving as the most important.
While the sessions in JavaPolis were well balanced on a wide gamma of topics (testifying the good work of the belgian guys), talking with people and looking at the "whiteboards" (a new tool that the conference introduced this year) I had the impression that a big deal of excitement is about things such as closures, new operators, scripting languages and so on (and this perception is consistent with the message that you get from blogs and forums).
While I don't have yet a matured opinion about these topics (my belly says no to everything, it fears a too high grow in complexity, but there hasn't been yet a briefing with my brain, so I'm not going to talk about it now), I'm worried about them being among the main focal points: sometimes too much excitement in the wrong area distracts us away from the real problems.
Let's put in in another way: does somebody think that having closures or the -> operator for properties or a neat integration with a scripting language will decrease significantly the rate of failed projects? Or will significantly increase the quality of our work, and the quality of services delivered to customers?
Before answering, please keep in mind that “project success” and “quality” are related to, but are not the same thing as “reducing costs” and “shortening the time-of-delivery”. More details below.
My answer is a resounding “no”. Having better tools is important, but the key to success is another thing: the process. Which contains stuff such as team building, a good communication plan with the customer, good risk assessment strategies (including thinking of "b-plans"), good design skills, knowledge of the technology, testing. This is what I've been taught (BTW, by Sun itself as an external consultant), I've been teaching for years, and what I've found in all my real-world experiences with customers.
I repeat, we need tools for performing well all these tasks, but tools aren't the thing that drives the process. It's the man behind the tool that does it. That is it should be. So I'm a bit worried as I don't see these topics under the focus in blogs, conferences and so on (at least, not in the same amounts as the closures stuff and so on). I'm scared at the thought that we all end up in the rush-fashioned, Microsoft-style method “give the customer what he wants today – or he believes he wants -, take the money and don't think of the future". I'd be really sad if this trend will drive the Java evolution – it would be a betrayal of the initial promises.
Let me draw a comparison with photography. What's the matter? Photography is an art, isn't it? Yes, as software architecture is. To be more precise, both the software architect and the photographer, even though in different proportions, use a mixture of science and art. You will hardly do good things with very bad tools, such as lenses made of cheap plastic or a poor programming language, but the key factor to success is still you, with your experience, knowledge and creativity. As a famous photographer says, “There's no such a thing as a lens that takes pictures by itself.”
Undoubtedly, digital cameras and sophisticated embedded image processors today make it easier to have a keeper shot, and the cost of each photo has lowered since the old times when you had to develop film in the wet darkroom. So better tools have indeed decreased costs and shortened the time of delivery. But the average quality hasn't increased. On the contrary, places such as Flickr are mostly filled with photos with no value, the typical “point-and-shoot” stuff made by “holiday photographers”, while professionals, even though they are very happy with their new tools, always pay more attention to “the process” (yes, they use this word too).
And as a final word, professional photographers are aware of the right priorities for tools. For instance, lenses are more important than cameras: most of the stuff that is packed in today's cameras is practically useless for a successful photo and often a good tripod is even more important than the camera body. We software guys should be aware of these concepts when we think of what to add to the Java platform.
PS Let me finish with an old joke which is popular among photographers. A pro has been invited to dinner by some friends and he's showing some premium-winning photos from his portfolio. During the dinner the hostess comments "Hey, these photos are really cool, you must have a very good camera!". He replies: "Definitely. BTW, this dish is excellent: you must have a very good pot".
Technorati tags: Java, software engineering, JavaPolis
Bookmark blog post:  del.icio.us  Digg  DZone  Furl  Reddit
Comments
Comments are listed in date ascending order (oldest first) | Post Comment
-
Great post Fabrizio !
Maybe we should repeat "IDE's in Action" again during JavaPolis 2007, so people can enjoy the overview of plugin's and dev. tools available on the market ?!
-Stephan
Posted by: sja on January 08, 2007 at 04:28 AM
-
Here's the trend that I see - it's all about the code:
Scripting, closures etc.
And discussing tools is better but IMHO, we have a bigger problem:
We need to get our head out of the code!
By which I mean we should spend more time at the 10000ft view in respect of not just tools but architecture and other considerations beyond just getting our hands dirty in the code.
These higher level topics are the ones where we get to drive biggest change and improvement. Which maybe explains why we've actually progressed so little in recent times.
Posted by: dancres on January 08, 2007 at 05:59 AM
-
Coding from 10000ft considered harmful.
Instead of thinking about code as getting your hands dirty, think of code as expressing requirements. That way, you'll want to improve the code, make it less dirty, rather than treat it as an inconvenient necessity.
When you do want to improve the code, you'll probably find yourself asking for BGGA-style closures (and other features that Lisp macros make trivial, like properties).
Posted by: ricky_clarkson on January 08, 2007 at 06:40 AM
-
"Coding from 10000ft considered harmful"
Agreed but I think you misunderstand me. Coding is not a means to an end in and of itself and we all spend too much time down there.
We can all code, we can all code fast but so what? Is it the right code to write? Are the requirements correct? Does the architecture hang together? Did we pick the right products to base our work on?
The big issues are not closures, scripting languages etc. The big issues are elsewhere and you won't see them if you hang on grimly to the coalface (0ft) view. That's something you only see from a higher perspective.
Posted by: dancres on January 08, 2007 at 06:52 AM
-
@sja: IMHO giving room to IDE's is a very good thing, because it's the right kind of tool where I'd put the focus, rather than on the language. For the remainder of JavaPolis, I think it was pretty good on the mainstream, while at the same time it reserved some space for new techs on the radar. Really, I wouldn't change much in the programme.
@dancres: I was betting that if you had spotted my post, you'd have commented in that way. ;-) And of course I agree.
@ricky I don't think that dancres considers code as a dirty thing, also because he has committed large amounts of code to the community. You're right, coding from 10000ft is harmful, but the whole sense of dan's metaphor is "use the elevation rudder". You can dive and fly close to the ground if you need, but you have to rise up to the sky to keep the overall sight of the battle (it's the reason for what they invented the AWACS, isn't it?). Cleaning up the code? Very good. I've been always keen to a sort of "aesthetic view" of the code. Use it for expressing requirements? Hmm, I see this as a mis-communication in most cases. For this reason I don't see any of the current code hop topics (closures, properties, etc...) as truly relevant for a project success.
Posted by: fabriziogiudici on January 08, 2007 at 08:17 AM
-
""use the elevation rudder". You can dive and fly close to the ground if you need, but you have to rise up to the sky to keep the overall sight of the battle (it's the reason for what they invented the AWACS, isn't it?)"
Like your metaphor better :)
Posted by: dancres on January 08, 2007 at 08:39 AM
-
"Like your metaphor better :)"
BTW all that diving and pulling up is also FUN ;-)
Posted by: fabriziogiudici on January 08, 2007 at 09:31 AM
-
What I see is a decline in the average training/knowledge of the java developer. They only have the "coalface" view because there are 10,000,000 in the trenches and 1,000 out seeing the 10K ft view.
Open processes allow the "masses" to contribute way more vote than they are often entitled too. So, we're fighting an up hill battle to maintain control.
Microsoft vs Java is the same problem.
Posted by: greggwon on January 08, 2007 at 02:04 PM
-
@greggwon: I agree with your view. Unfortunately it's a well estabilished trend.
Posted by: fabriziogiudici on January 08, 2007 at 05:14 PM
-
I am not in the camp that believes in revolutionary change to Java but I do think you need to evolve the language. See this blog:
Clear, Consistent, and Concise Syntax (C3S) for Java
The reason that I see the need to evolve the language is that attracting new developers is critical to keeping momentum. You only attract new developers if the language is competitive with newer languages. If you have new developers and sustained momentum then you get better tools and better libraries and hence better solutions to problems. Lets not forget that Java success was partially that it brought clean OO and garbage collection into the main stream - it was at one point at the forefront!
Posted by: hlovatt on January 08, 2007 at 07:42 PM
-
hlovatt, I understand this "marketing" necessity of keeping high (and increase) the interest on the language. It makes sense. However it's important, IMHO, that the "masses" are controlled in some way, that is the governance behind Java should lead them instead of following. After all it's how Java was born: a small group of researches spotted a problem in the real world, they closed in a lab, and came out with a proposal. There was some marketing thing (e.g. the syntax similar to C++ instead of a new one), but there was also a strong governance (e.g. KISS, don't give people too many ways to do the same thing, etc) - theoretically Java was less appealing than C++ as it forced the programmer in some way. Nevertheless it won over C++.
Given that, I'm not contrary by principle to an evolution of the language. I'd only like that at the same time somebody told people that there are also most important things to look at.
Posted by: fabriziogiudici on January 09, 2007 at 01:15 AM
-
I've seen tons of bugs that would be easier to get right with closures.
Posted by: tompalmer on January 09, 2007 at 08:15 AM
-
Things like closures won't significantly decrease the rate of failed projects or the quality of our work, any more than technologies like object-oriented programming, garbage collection, or test-driven development did. Nor will they create whirled peas. But they make these things easier to accomplish.
There isn't a silver bullet, and it would be wrong to suggest that we shouldn't work on anything but the one true silver bullet. Progress comes in small steps.
The pro photographer prefers a very good camera, even though it is not sufficent to get good photographs.
Posted by: gafter on January 09, 2007 at 08:46 AM
-
I strongly disagree with part of the first sentence. Object Oriented Analysis and Design (not Object Oriented Programming) changed _a lot_ in the failure/success ratio of projects, mostly because of the method it introduced: iterative and incremental. This has been a real perspective shift, and I don't believe much of the existing ultra-integrated services (banks, e-commerce, whatever) could exist without it, as the i&i method is required to take care of changes during the project life (conversely I believe that if the scenario hadn't turned into high rate of specs change and high integration, OOAD wouldn't have had a great popularity).
Many project still fail in spite of the fact they use OOP technologies because they don't follow OOA&D methods.
Garbage collecting is just a language technology, but as it relieves from the pain of defining the ownership of memory, it has a dramatic impact on the architecture and design, not only on the implementation.
PS most professional photographers buy the top-of-the-class cameras for many reasons, including sponsorship ;-) , but mostly because the top models are more rugged and reliable. On the contrary I recently made a quick survey about camera models used by the winner photos of a world-famous BBC photo context (open also to non-professionals), and roughly one-third of them were just prosumer cameras. This is just an example, but I find it illuminating.
Posted by: fabriziogiudici on January 09, 2007 at 09:11 AM
-
...As my mother used to say, "do you really need that?". And usually, after a little thought, the answer was almost always "no". This is true of just about every "feature" that was rolled into Java 6 and what looks to be rolling into Java 7. I'd rather see the VMs improved, the compactness improved, etc. As John Irving said, "I remember you when you were young, but when I look at you know, I don't know who you are". Man, that fits pretty well with Java 6 and 7...
Posted by: alski on January 09, 2007 at 09:30 AM
-
Hey Fabrizio
I don't think any of the current language change proposals are really trying to fundamentally alter the ratio of failed/successful projects. Anybody who's been in this business for a while knows that project failure is a much more complicated scenario, and that there are no silver bullets.
Rather, in my view, the language changes that are being considered are all about productivity, and developer enjoyment. Who likes writing, reading, maintaining, testing or commenting a bunch of boilerplate methods? Who wants to write a paragraph of code when a single sentence would express the same thought?
Posted by: rbair on January 09, 2007 at 10:26 AM
-
edit: I was just rereading my post and wanted to clarify: I really enjoyed your posting, and agree with the general thread that "the process" is the largest determinant to success. My point is just that those of us who support language enhancements are really interested in enhancing the coding experience, not providing a silver bullet.
Posted by: rbair on January 09, 2007 at 10:30 AM
-
There has been also some follow-up on TheServerSide where I clarified that my whole post is not against the fact that people is working on new language features (as I've said I don't have yet a mature opinion on them, I've got a negative attitude but I could change my mind once I see a more defined proposal).
My worry is about the expectation that the community has about them as silver-bullets, as I perceive it too much unbalanced on code (probably because there are too many developers and too few architects, and probably many companies don't understand that this is an error). In fact, in the end all the threads originated by the post have ended up in some discussion about closures or Groovy, in spite of the fact that I didn't want to talk about them (yet). :-)
BTW I saw that there's a new thread on JavaLobby focused on the new language features.
Posted by: fabriziogiudici on January 09, 2007 at 10:45 AM
-
BTW, about productivity, apart from the fact that I agree with Dan that architecture can play a major role also in this field, I'd expect to gain it more from IDE support than from the language. But again, I don't have yet a strong position on this topic.
Posted by: fabriziogiudici on January 09, 2007 at 10:50 AM
-
Things like closures won't significantly decrease the rate of failed projects or the quality of our work
I partially agree with this:
The quality of my work depends mainly on the quality of my team.
A high quality team may produce higher quality projects with the aid of closures.
But I'm afraid that a normal team will produce poor quality projects with the introduction of closures. Closures are just one more thing to learn, to understand, to gain expertise on. This is: just one more degree of freedom to keep under control.
I understand that closures are really cool, and are probably a good marketing thing, but I still cannot find a use case where the complexity that closures introduce is smaller than the benefits they provide.
Cheers,
Antonio
Posted by: vieiro on January 10, 2007 at 01:07 PM
-
I agree with sja: This is an excellent post.
I don't think that the language itself is the source of such low porject success rates... The problem lies much further up the food change and closer the definition of the projects themselves. Language features help us implement a bit more efficiently... but our problems are often in understanding and even agreeing on what it is that we should be implementing in the first place.
-JohnR
Posted by: johnreynolds on January 10, 2007 at 02:32 PM
-
Thanks Fabrizio, there are many of us out here that feel the same way.
Posted by: kdw on January 11, 2007 at 12:44 AM
-
Fabrizio said:
"Use it [code] for expressing requirements? Hmm, I see this as a mis-communication in most cases."
It is arguable that the language of the solution should be as close to the language of the problem as possible, hence the area of Domain Driven Design.
The ultimate in that would be if requirements were expressed in code. I realise this is a difficult, if not impossible task, but it's an ideal. That's why I think high-level code should be understandable by the layperson. I really mean the layperson here. Instead of having them come to us and learn programming, we go to them, by making our language look like their language.
Anything that helps to make our code higher level makes it easier to express a problem domain in, and hence takes us closer to the customer.
Posted by: ricky_clarkson on January 11, 2007 at 04:27 AM
-
Domain Driven Design is on my radar, I think there could be useful hints in it. At the moment I know just a bit about it. But as for using it as a specification description: it's mere utopia. :-) Sorry to be so sharp, but it's not by chance that I put "communication plan" as the second item. Communicating is already difficult in natural language, even with customers which are technical. Add a (natural) language barrier in the middle. Customers don't want to learn other languages, they only want their problem solved.
Maybe it works in some cases, perhaps when the customer's background is really close to yours. But if it's really so close - well, he's probably able to solve his problem by himself. :-) In any case, also for DDD it's just belly sensation at the moment - I'll made my mind later.
Posted by: fabriziogiudici on January 11, 2007 at 05:54 AM
-
Great article. I agree at 100%.
Complimenti, ;-)
F.Gianneschi
Posted by: bitog on January 11, 2007 at 02:13 PM
|
java.net RSS Feeds
