WTF is this blog post about - you might ask yourself?
Well, it's about Java. And it's about how Java is right now in the discussion to be the new COBOL. And it's about a handful of bored minds who wish it would go away to leave the space for the wonderful academic world of LISPs. Oh, wait. Didn't they say, LISP is also dead? No? Does it come back again as Clojure? Hm. And they said, C++ is an old hat, but it's still there, and it's starting into the next round and it looks cool I must say with all its new features. And it has its fans, quite a lot. And it has its place. So, why not?
Now, there is Java. The ultimate enterprise platform of the past decade, beside .NET. Both are responsible for the growth of millions of businesses as IT enablers. Both still drive them. Both will drive them in the future. Both (now) allow multiple languages on the common platform, but the most used are Java and C#. And why? Because they are simple! These languages can be learned within a few hours - concerning their syntax, and then you only learn the rich extended features and libraries and idioms.
But even because they are simple, a sophisticated mind quickly gets bored with them. Sure, it's normal. And of course every good programmer should learn a new language every now and then. But what I can't stand is the campaign against one language or another. And what is really stupid is the daily invention of a programming language. One-man-programming languages. What for? Who does need them? Guys, you better concentrate on improving of the existing ones! If people on Earth would invent spoken languages as often as you do invent programming languages, the planet would become very quiet. It seems to me that these days, instead of finding idioms in one existing programming language to solve a concrete problem you just invent a completely new programming language just for this purpose!
Now to the discussion about Java as dying inferior bashing enterprise language. Well, millions of outsourcing companies will be happy to hear this, and managers don't give sh... to academic beauty of the Clojure code. For example, 30 bucks an hour is a good price, sounds great and much cheaper than what an average Java consultant earns these days. Before another languages will have a chance to come as far as Java is right now - struggling themselves with academic features and discussions around the squaring the circle programmaticly, all the nice jobs are gone to India and East Europe again. Is it really what you all want?..
Even if your mind is bored - don't make the mistake, don't bury Java, don't believe it's gone. You can't compare it with COBOL since it's running completely different paradigmas, scales well for some scenarios, abstracts perfectly and is very open and extremely well supported. And it's simple. It could be simpler, but it's ok. Its only problem is that it's not academic :), and it could scale better if it would have some elements of functional programming so the developer won't run into side effects. And I repeat myself every now and then, ok, but this also can be solved through language improvement. Do you miss much more there? I don't, the rest is pretty subjective, really.
I don't judge languages, I judge solutions. With Java and how it's established, I can solve everything. What gets compared with it, is almost experimental right now, so can't be compared.
To me, the ultimate bored minds who already bury Java are just... bored minds. They are no coffin nails.
4/24/2010
4/17/2010
DevRoulette
I had this thought a couple of days ago, and I have tweeted it. And hey, why not?
We have seen the ChatRoulette, which is ... well ... kind of ... here around. My idea is completely different, but with the same portion of randomness. And it's for geeks.
Imagine the following process:
Now, where would the tasks come from? I would suggest that the platform offers a feature to everybody to setup a task. Tasks could be:
And so on. It's a game, but a technical one, and you can keep your brain busy and learn a lot - through solving problems in a short time, through team work and through asking precise questions so the corresponding problems can be solved within a short time.
That's the idea. And I would like to call it the DevRoulette. I would love to share this idea with the community, so comments, discussions, ideas etc. are very welcome. Interesting thing is the implementation aspect since it's not that trivial.
But by myself, I like the idea. Please forward it to your friends - maybe someone also likes it.
We have seen the ChatRoulette, which is ... well ... kind of ... here around. My idea is completely different, but with the same portion of randomness. And it's for geeks.
Imagine the following process:
- you log into a platform
- you get connected to a random session to someone you don't know who's hiding behind a random alias - another geek
- you two get a task from a pool (more about it a little later) and 20 minutes to solve it. The task will be assigned based upon your skills (more about it a little later)
- If you solve the task, you two earn points. If you don't - you don't. In either case, the session is over and you can go on with another session or log out
Now, where would the tasks come from? I would suggest that the platform offers a feature to everybody to setup a task. Tasks could be:
- unit tested - immediate result - immediate points
- asynchronous - for complex questions or non-unit-testable languages or progs, so the author has to check the answers asynchronously
And so on. It's a game, but a technical one, and you can keep your brain busy and learn a lot - through solving problems in a short time, through team work and through asking precise questions so the corresponding problems can be solved within a short time.
That's the idea. And I would like to call it the DevRoulette. I would love to share this idea with the community, so comments, discussions, ideas etc. are very welcome. Interesting thing is the implementation aspect since it's not that trivial.
But by myself, I like the idea. Please forward it to your friends - maybe someone also likes it.
4/16/2010
My New Book: "Fragile Agile"
Yes, this is true: my new book will come soon. Together with my co-author Michael Hüttermann we are finishing it. It's called "Fragile Agile". You can find some details on it as well as the cover pic on my web site.
4/15/2010
TEA - Telepathy Expecting Architecture
I would like to introduce the ultimate technology breakthrough, so to speak the holy grail, the one so many architects have been looking for through all these years, the final truth which solves any IT problem that could ever come around.
The name of this divine thing is: TEA.
And TEA means: Telepathy Expecting Architecture. Let me tell you the story behind it, so you know the history of this world moving element.
Once upon a time, in an early project phase, I've been talking to a customer about his non-functional requirements. As usual, he didn't want to think about them, and kept on telling me he would like to ignore them all since he's thinking totally pragmatically, and that I would just waste his time with that Cosmic Debris.
Me, I've learned to ignore arguments like that and to keep on doing my job. So at one moment, we are at the point where I ask him about how long it should take for a follow-up page to come up after the user has submitted the previous form - averaged. And he tells me: immediately.
I say: ok, what is "immediately"? 5 sec.? 10 sec.? He says: not even 1 sec. Even immediately.
I say: hey, we're on the web, stay realistic, man.
He says: but we can buy better servers. Mr. Smith - our inhouse architect - has told me it's no problem.
Mr. Smith, huh... I ask him: did Mr. Smith also tell you about things like network latency and stuff?
He says: yes, and there's absolutely no problem - with bandwidths these days, you know
I ask: can you please tell me how he measured the facts for his keen statements? I mean, have things like different "weight" of different functions in the platform or seasonal business been taken in account and so on?
He says: measure? Hey, it's waste of time. We don't use your scientific methods. We work pragmatic - get down to it and get it done.
I say: well, that's very laudable. And did Mr. Smith also tell you that it's going to be pretty expensive to get started like that - with a huge chance of failure? I mean, you throw a couple of monster servers and a fat cable pipe at a completely new solution without having an idea of how it behaves in production over a considerable time period, during load peaks etc. You don't know anything about the future code quality, bottle-necks in there, the middleware bugs, external attacks that hit you every minute and slow you down like hell, about your partners who save hard links to sticky sessions and thus kill your load balancing - if Mr. Smith plans load balancing at all. You have no idea about all that, and you and Mr. Smith, you both are sure you need and will have 1 sec. gross response time per any action in your web platform?
He says: Mr. Smith told me, our users need the performance and don't accept anything slower than 1 sec. per action. And I believe him, because he works for us for now 20 years and has already proven his loyalty, which is more than I can say about you.
I say: I see. In this case, I think I know which architectural pattern or approach Mr. Smith has picked for your new solution, and I'm sure it will work for you! Not many companies have used it before since it's not very popular - not many believe it's successful. But you seem to do.
The name of this approach is TEA - Telepathy Expecting Architecture. It absolutely guarantees that any action between the user click on a button on the client and a new page showing up on his screen takes an absolute minimum of time - much less than 1 sec. How it works?
Very easy: through telepathy. A telepathic component built into the client part of the application (web browser) talks over any huge distance to the corresponding telepathic component on the other side on the server which sends data back - also through telepathy. Easy. Fast. No overhead. No latency. No physics. No chemistry. Data just... appears here and there. Cool, huh?
What's the catch? Well, you only need to build the both telepathic components - that's the only challenge.
He says: .......................................
TEA - it rules. Coffee - it sucks - it's just a too long name.
The name of this divine thing is: TEA.
And TEA means: Telepathy Expecting Architecture. Let me tell you the story behind it, so you know the history of this world moving element.
Once upon a time, in an early project phase, I've been talking to a customer about his non-functional requirements. As usual, he didn't want to think about them, and kept on telling me he would like to ignore them all since he's thinking totally pragmatically, and that I would just waste his time with that Cosmic Debris.
Me, I've learned to ignore arguments like that and to keep on doing my job. So at one moment, we are at the point where I ask him about how long it should take for a follow-up page to come up after the user has submitted the previous form - averaged. And he tells me: immediately.
I say: ok, what is "immediately"? 5 sec.? 10 sec.? He says: not even 1 sec. Even immediately.
I say: hey, we're on the web, stay realistic, man.
He says: but we can buy better servers. Mr. Smith - our inhouse architect - has told me it's no problem.
Mr. Smith, huh... I ask him: did Mr. Smith also tell you about things like network latency and stuff?
He says: yes, and there's absolutely no problem - with bandwidths these days, you know
I ask: can you please tell me how he measured the facts for his keen statements? I mean, have things like different "weight" of different functions in the platform or seasonal business been taken in account and so on?
He says: measure? Hey, it's waste of time. We don't use your scientific methods. We work pragmatic - get down to it and get it done.
I say: well, that's very laudable. And did Mr. Smith also tell you that it's going to be pretty expensive to get started like that - with a huge chance of failure? I mean, you throw a couple of monster servers and a fat cable pipe at a completely new solution without having an idea of how it behaves in production over a considerable time period, during load peaks etc. You don't know anything about the future code quality, bottle-necks in there, the middleware bugs, external attacks that hit you every minute and slow you down like hell, about your partners who save hard links to sticky sessions and thus kill your load balancing - if Mr. Smith plans load balancing at all. You have no idea about all that, and you and Mr. Smith, you both are sure you need and will have 1 sec. gross response time per any action in your web platform?
He says: Mr. Smith told me, our users need the performance and don't accept anything slower than 1 sec. per action. And I believe him, because he works for us for now 20 years and has already proven his loyalty, which is more than I can say about you.
I say: I see. In this case, I think I know which architectural pattern or approach Mr. Smith has picked for your new solution, and I'm sure it will work for you! Not many companies have used it before since it's not very popular - not many believe it's successful. But you seem to do.
The name of this approach is TEA - Telepathy Expecting Architecture. It absolutely guarantees that any action between the user click on a button on the client and a new page showing up on his screen takes an absolute minimum of time - much less than 1 sec. How it works?
Very easy: through telepathy. A telepathic component built into the client part of the application (web browser) talks over any huge distance to the corresponding telepathic component on the other side on the server which sends data back - also through telepathy. Easy. Fast. No overhead. No latency. No physics. No chemistry. Data just... appears here and there. Cool, huh?
What's the catch? Well, you only need to build the both telepathic components - that's the only challenge.
He says: .......................................
TEA - it rules. Coffee - it sucks - it's just a too long name.
4/14/2010
Code Monkey vs. Code Donkey
You sure know who a Code Monkey is. Meant positively, it actually means a good guy - a coding guru. Managers are after him, 'cause he produces tons of code. Customers are after him, 'cause he is an enabler. Girls are after him, 'cause he's sexy (well, at least the Axe / Lynx ads tell him that).
Right? Well, that's the image. The problem with this image is that a couple of those who think or would like to think they are Code Monkeys are actually Code Donkeys - intendedly or accidentally, and the difference is a little bit more than just one letter and biological species.
Let me give you a couple of very different technical and psychological examples of what I mean is a Code Donkey:
It's not the speed of your typing or the amount of yout tweets and thus the alledged coolness. It's how you act. And to be a guru, you need to act professionally.
Right? Well, that's the image. The problem with this image is that a couple of those who think or would like to think they are Code Monkeys are actually Code Donkeys - intendedly or accidentally, and the difference is a little bit more than just one letter and biological species.
Let me give you a couple of very different technical and psychological examples of what I mean is a Code Donkey:
- Breaks the builds - sometimes or often
- Uses VCS as code backup system
- Suffers from Goodnight-Commit syndrome
- Suffers from Superhero syndrome overestimating his own capabilities and thus quickly becoming unreliable
- Never blames himself for a failure, blames all the others for everything he did wrong
- Just randomly doesn't answer to emails or questions
- Hunts every new technology hype, screwing it into the current solution, no matter if it fits there or not
- Knows everything better and ignores best practices or suggestions from the others
- Doesn't share knowledge, i.e. doesn't mentor juniors
- Doesn't document and comment his code well
- Prefers talking over listening in meetings or in other gatherings
- Criticizes formalism of non-startups showing how "easy" it is to just peg down the code without all those layers, abstractions etc.
It's not the speed of your typing or the amount of yout tweets and thus the alledged coolness. It's how you act. And to be a guru, you need to act professionally.
4/06/2010
Technical Gurus Run Into The Social Bog
Recently, I've listened to a podcast episode where a couple of very well known software architects were supposed to talk about the software architecture. The audience could also ask questions, and everybody was sure this all will be about layers, components, interfaces etc.
After the first half hour, the host has publicly noticed that no single word about technology has been spoken yet. All those guys were talking about the teams, the people, how to sell architecture, how to win developers so they would find your technical stuff cool or whatever.
Being pointed at this problem, they have tried to turn back to the original idea, but it didn't seem to matter at all since the all just wanted to speak about the social, the soft aspects of architectures. Even after the audience asked some technical questions they just kept on returning to this non-technical social stuff.
And so, throughout the whole podcast they have just talked about what they have called "architecturing" and not about the architecture. Or almost not at all about it. But why that?
Well, the answer is very simple: you can read a book about technical aspects of the architecture, but noone will teach you its soft aspects (actually, almost noone - in my own book I try to approach exactly that - but I don't advertise it here :) ). Technical gurus run into the social bog first time they notice that even when their architecture is techically brilliant nobody wants it because people just want to do another platform or just want to keep their jobs without a major change etc.
Does technology help us understand all these factors? Never! What does? Experience, listening to other people, learning from people and companies.
Technology is fun, but not more than that. What really matters is the ability to use the right technology in the right place at the right time even if it's completely uncool or just sucks. If this technology (or as its surrounding term - the architecture - the way the technology is used to provide a winning solution) satisfies the maximum of all social aspects and needs of all stakeholders who are in the boat (and hey, this can be so many), it's a good technology or architecture.
If it doesn't, it's nothing else but a useless toy. And how to build them, you can read in a couple of cool books.
After the first half hour, the host has publicly noticed that no single word about technology has been spoken yet. All those guys were talking about the teams, the people, how to sell architecture, how to win developers so they would find your technical stuff cool or whatever.
Being pointed at this problem, they have tried to turn back to the original idea, but it didn't seem to matter at all since the all just wanted to speak about the social, the soft aspects of architectures. Even after the audience asked some technical questions they just kept on returning to this non-technical social stuff.
And so, throughout the whole podcast they have just talked about what they have called "architecturing" and not about the architecture. Or almost not at all about it. But why that?
Well, the answer is very simple: you can read a book about technical aspects of the architecture, but noone will teach you its soft aspects (actually, almost noone - in my own book I try to approach exactly that - but I don't advertise it here :) ). Technical gurus run into the social bog first time they notice that even when their architecture is techically brilliant nobody wants it because people just want to do another platform or just want to keep their jobs without a major change etc.
Does technology help us understand all these factors? Never! What does? Experience, listening to other people, learning from people and companies.
Technology is fun, but not more than that. What really matters is the ability to use the right technology in the right place at the right time even if it's completely uncool or just sucks. If this technology (or as its surrounding term - the architecture - the way the technology is used to provide a winning solution) satisfies the maximum of all social aspects and needs of all stakeholders who are in the boat (and hey, this can be so many), it's a good technology or architecture.
If it doesn't, it's nothing else but a useless toy. And how to build them, you can read in a couple of cool books.
Subscribe to:
Comments (Atom)