good points, but not entirely true
on
Dow vs. Parody
·
· Score: 3, Insightful
" leveraged buyouts and hostile takeovers , all done on a global scale, were already a century or more of old news before the first shot of the revolution was fired on the green at Lexington."
This isn't entirely true. Large-scale corporations (the size of Hudson Bay or East Indian, which were exceptions) didn't really emerge until the late 1800's.
Another note is the fundamental disconnect in power between management and shareholder. Certainly businesses started with owners that "hired hands" to run the place. But eventually (WW2 and beyond) management rose as a distinct discipline and practice. Management held a tremendous amount of what could be almost called "illegitimate" power.. that is, until the backlash of hostile takeovers of the 1970's and 80's. Hostile takeovers before this time were quite rare... and it's really what started the whole "maximize shareholder value" fad we hear about today -- if you don't keep your stock price up, you'll get raided.
I was looking to buy a console this Christmas, and was leaning towards the PS2. I'm not a particular fan of Microsoft, though I'll use their products if they're good (for example, Mac Office 2001). Anyhow, I haven't really kept up with the console market, and XBox Live really was the reason I changed my opinion and picked up an XBox -- my first console since an original NES. I've had a great experience with it these past 3 weeks.
After catching up with the market and playing my new toy, here's a reflection of my rationale for choosing the XBox and XBL:
- I have a cable modem, and I would refuse to use anything but a broadband solution
- I don't want to deal with annoying inconsistencies in multiplayer setup between game titles. XBL has a relatively consistent set of terminology between games.
- I really do appreciate the Microsoft "single source" approach, for now. I don't have a problem paying a nominal monthly fee for a better overall experience (which is what I feel I'm getting thus far).
- The variety of XBL games available is WONDERFUL. I picked up NHL 2K3, Unreal Championship, and MechAssault. (I also grabbed Splinter Cell, which alas is single player, but still great).
- The voice communicator is a nifty add-on, and works relatively well.
As for the quality of games:
- MechAssault is my fav, best experience since MechWarrior 2. It actually has some elements of strategy involved with assault compared to other shoot-em-up's. The single player missions are fun too. Well worth the buy for me -- but I know some friends that don't think much of it because they just don't like the shoot-em-up genre.
- Unreal Championship is tons of fun, just what I would expect if I were playing it on a PC or Mac, though the graphics aren't as good as a high end PC, and sometimes lag gets a bit much
- NHL 2K3 is very rich, graphics aren't as good as EA's but the gameplay is really great. I have a learning curve to get through, unfortuantely.. advanced modes can be tough for newbies to sports games (which I admitedly am)
- and (non-XBL) Splinter Cell is one of the best adventure games on the market right now, IMHO.
What don't I like? Well all in all, the price was rather steep after buying 2 extra controllers, an advanced AV kit, 4 games, XBL, and a console (which had 2 games bundled). That put me back around CDN$800 after taxes. Games run around CDN$70/each at Best Buy. How the hell can parents afford to give this to their kids?
XBox really seems to have been well executed. I have no troubles supporting Microsoft in this product arena, provided they continue to make a great product. It remains to be seen if the market at large will make it a profitable platform, though hopefully it will -- it will keep Sony, Nintendo, et al competitive.
Again, if you think Java's collections libraries are such a dream, you haven't read the code or even understand what is going on.
Ah, so instead of enumerating rational reasons as to why J2SE Collections are somehow "terrible", you are attacking my expertise which you have no knowledge of. And I never claimed they were "a dream", I suggested I was quite happy with them in general.
"You should check out a few good libraries such as JGL."
I have used JGL since 1996, and it is excellent, quite a lot more features than J2SE collections.
To even compare Java to a Smalltalk collections libraries or stdc++ is pretty shortsighted.
Our disconnect here appears to be in what I'm comparing. You're comparing feature-for-feature. I'm comparing the simplicity and practicality of them. The J2SE collections are very simple, very powerful, and a good "base" collections library. stdc++, JGL, ST libraries are all very "complete" libraries suitable for a myriad of situations, but do not lend themselves well to learning or understanding quickly.
I am certainly not attempting to claim that J2SE collections are a step forward in the evolution of collections -- the point is that they were never intended to be. Why call something terrible if it never aspired to be anything other than simple, relatively powerful (vs. JDK 1.1), and easy to learn?
(regarding J2SE 1.4 I/O).... it is still far from what it needs to be... Although, it is far better than what used to exist... it is far from seamless and far from transparent.
What does it need to be? Transparent from what? Transparency is not a universal principle. And what seam do you speak of, the unavoidable one between old I/O and new I/O (which is a relatively decent integration at the moment), or another?
Java has no real idea of thread priority.
An unfortunate tradeoff when working in a cross-platform environment. The priority heuristics in the JVM are largely dependent on platform.
Notify/yield/wait is extremely unpredictable with no real guarantee as to what can happen when a thread is notified.
Yield, like priority, is a heuristic hint, for the reasons above. As for notify/wait, they're well specified as to what happens when a thread is notified -- the main problem is the lack of guaranteed fairness. So, it's theoretically impossible to prove fairness in the thread model, again a tradeoff due to platform portability. In practice, most JVM's exhibit probalistic fairness and have relatively sophisticated schedulers.
Note that none of this prevents any JVM from providing their own non-portable APIs for strict priority scheduling or FIFO lock queues. And some of the embedded VMs do provide this, IIRC.
Stopping threads is extremely cumbersome.
Stopping threads arbitrarily is dangerous and I'd really like to understand why there should be an alternative way to do this other than an application-specific mechanism.
Inter-thread communication is difficult.
This is a matter of taste. Communication via shared object state or through other means... which is easier? Depends on the programmer, depends on what you're trying to accomplish. Guarded Wait/Notify is a pretty understandable approach.
I'm not going to go into more details except to say that you may feel that J2SE 1.4 is a gift to the masses, but in reality, there are core issues that still remained unsolved.
It is easy to criticize and call something "terrible" when you don't take into account the goals and priorities of the effort.
I never said J2SE was a gift to the masses and solved all problems. I just disagreed about some of your criticisms, as they seemed to be based on "anything that doesn't meet exactly my need right now sucks" and was completely devoid of the context of the tradeoffs in the features as Sun has implemented them.
Most certainly Sun has made many mistakes: ThreadGroups are ridiculously useless, as are the Java 1.0/1.1 collections, the Java 1.0 event model, taking over 5 years to evolve Swing, not fostering a plethora of look and feels, not giving any real documentation on writing performant Swing programs.
"I do feel that with what IBM is doing, others will follow IBM's lead and develop other extension libraries that are better than the Java core itself. IBM has proved it can be done, and can be done without modifying the core."
In a way, I hope you're right... but I don't think it's the direction the industry is taking.
.NET is one of many things, depending who you talk to in Microsoft's marketing dept. First I'll define that. Forgive me if it's review.
Here's the things that it isn't (in reality): - A new server platform (MIcrosoft marketed it as such, even though there really isn't anything new in their Windows 2000 lines of servers yet). - A some new magic technology (i.e. the marketing idea that MS Passport became Passport.NET and thus was embued with a +6 long-sword)
Here's what it is: - The common type system, language spec, and language interface. (CTS, CLS, and CLI). It's a way of getting several languages to interoperate through a virtual machine.
- The Common Language Runtime (CLR) for Win32. This is the Virtual Machine. It's as fast as Java 1.4 in some ways, slower in some ways, and over 2x faster at certain operations like object creation. Ya gatta hand it to Microsoft's x86 team, they know their stuff.
- The following languages are released by Microsoft for.NET: C#, VB.NET, C++.NET, and JScript.NET. C# is first among equals, but VB.NET can do anything C# can do, again because the CTS/CLS is "the language"..NET just gives you a syntactical skin on top of this abstract language.
- The Base Class Libraries (BCL), ASP.NET, COM+ (aka Managed Components), and ADO.NET are included.
- The ECMA standards body has been submitted the CLI, CTS, CLS, BCL, and C#. Mainly for show, but maybe something good may come from Miguel et al.
What's.NET good at?
- It's a much better way for binary module interoperability than COM was. Viewed this way,.NET could be seen as the next step in evolving binary interop. I.e. in DOS, it was TSR's and interrupts, in Win 3.1/*nix it was DLL's and pointer-tables, in Win95+/Gnome/KDE it was COM or CORBA components, and in.NET, interop is at the CLASS level. They've basically learned the Java/JAR model of interoperability, then abstracted it to multi-languages (they just call JAR files "assemblies")
The language-interop issue at first glance seems like a red herring feature, but in fact it's rather important from a programmer's sociological perspective. VB and C++ programmers are naturally opposed to each other in philosophy - their means and ends do not peacefully coexist..NET makes all languages equal. This was painfully NOT TRUE in COM programming! Almost all of the plumbing underneath COM was to support Visual Basic's interoperability with C/C++ components..NET levels the playing field here, and people can't pick on VB anymore (other than its cheesy syntax). Anyone can throw an exception in C# and catch it in VB, or define a class in C++ and inherit from it in C#. And debug across all these languages in a single session, if need be. Quite liberating for system architects dealing with a large, multi-team project with reusable components and potentially different skill-sets (hence different languages).
Things you can do with.NET DLL's that are better than traditional Win32 COM DLL's: - The Windows Registry is NO LONGER NEEDED. Nothing in.NET uses it, sing the praises! - Easy and Flexible Side by side versioning. An app that links against a version stays with that version unless updated or a sysadmin coerces it to use a newer DLL version. - No filename conflicts (i.e. no 2 vendors with MYSILLYLIBRARY.DLL overwriting each other -- each DLL has a public key stamp)
Other things... Making web services in.NET is CHILD'S PLAY compared to some other platforms. Especially with Visual Studio. They've really made distributed interoperability easy -- though of course none of this will scale or be bulletproof without real engineering work, but that's never been Microsoft's game -- let J2EE vendors do the dirty guinea pig work, they'll copy it into Windows/IIS eventually.
So -- you see,.NET really is about making Windows developer's lives A LOT EASIER. Which really was all that Visual J++ 6.0 was about before they decided to "break" features for political reasons. The jury's still out as to whether.NET is appropriate as a new standard for dynamic languages like Smalltalk, Lisp, Haskell, ML, etc.
I say it's more about "syntax skin" than "flexibility". Certainly you can write Lisp onto.NET but you have to contort it into classes & methods if you want to interoperate with any other.NET language... this is what the C++ people have to do too! (i.e. no more templates, multiple inheritance, at least until.NET 2.0:).NET isn't the second coming, though many Missy-followers think it is because their intranet is locked to http://msdn.microsoft.com and really don't have a lot of exposure to the alternatives out there (i.e. J2EE or perhaps PHP, Python, Ruby, etc.)
No, I think VB should be cast out into the depths of hell from whenst it was created.
But it still is the most popular client-side language in the world.
Regardless of the politcial debates surrounding.NET, it is much, much, better than Microsoft's prior technology platform (DNA, "we put the COM in COMplex"). They've created a high quality framework and platform. I wouldn't say it's vastly superior to Java, but it's certainly competitve in some areas (not in others).
"They ignore simple physical facts. like the fact that normal property has natural limits in supply and demand - that imply markets and property law, but that information has no natural limits."
Really? Let's dig a bit deeper, shall we. We'll see this isn't entirely true.
"Information" is an abstract entity, devoid of the human effort surrounding it, so at first glance it doesn't look to be subject to supply and demand. But on second glance, we recognize that economics is the discipline of applying scarce resources (natural resources, labour, capital, and some might say "knowledge") in the face of unlimited demands. And with regards to information, there really are only two major kinds of demands: distribution & creation.
The cost of distributing information is usually tied to its distribution vessel, its medium. Such mediums typically are physical, and hence, scarce (a mouth uttering words, a diskette carrying software in a shrink-wrapped box, etc.). Thus information distribution is subject to supply & demand, in the general case.
The combination of widespread Internet access and digital representation of information has created a situation where information is "on tap", like water, and hence has effectively a negligable economic value -- though not zero. Why not zero? Well there's that ISP fee, similar to your house's water fee. Another note is that some information requires large pipes -- downloading full DivX movies, for example -- and most people don't have large pipes (yet), and pay a premium for them.
This information/tap water metaphor is making me think of beer, so I'll switch angles and refrain from running to the corner pub.
Ok, so if information distribution has negligable economic value (in theory), we must turn to information creation.
Creating something intangible, like information, is effectively a service. What economic resources are involved in creating information? The traditional resources of the economist -- land and labour aren't really used all that much (capital IS used, but not so much as a "factor" of producing information so much as an "aid") but the "new" central resource of our evolving post-capitalist economy, knowledge (perhaps even talent), certainly is involved. We know very little about the economics of knowledge. But we do know that it has become the central factor of production in any modern economy. And it is central in producing information.
Knowledge, by its very nature, is scarce -- it is not held on a disk, or in a book -- it is held inside your brain. It requires a significant ramp-up time to turn information into knowledge. And there are many bodies of knowledge out there -- many specialities -- that are all required by different people at varying levels of demand. There are different tastes in genres of music, different kinds of software, different genres of movies, and different roles in the creation of all of these works of information -- the credits list of any big-budget movie will attest to the wide variety of knowledge required for making a movie.
So I think it's really clear that there is some kind of scarcity surrounding information creation -- supply/demand exists both in the KIND of information we want created and in the KNOWLEDGE needed to create information. It's the knotty issue of actually setting a marketplace AROUND information that is our problem -- the productization of information is the fallacy that must be overcome.
Some things, like movies, will always have scarce distribution channels like movie theatres to rake in the dough. Music and software will probably require entirely new business models.
One suggestion for a new business model is that perhaps instead of "buying" a CD or piece of software, an artist and/or company will solicit "contributions" to create MORE information. This could work well for music -- the market will support the artists that they wish to make a living at what they do so they can make more music. I'm not sure if this makes sense for software yet, given the higher capital costs to get a product out the door.
I've written quite a few Swing & server-side applications myself.
"Microsoft and MFC rules on the client side (on Win32)".
MFC is dead, long live.NET. And Visual Basic rules on the client Win32 side, and has for quite some time.
"But now, Java needs to become a viable alternative to C++ based programming on the client-side."
Absolutely not. Java's only main competitor for Win32 client-side supremacy is VB.NET and C#.NET. C++/MFC is a dead-end.
On UNIX, I would suggest it's a toss-up between C++/Qt and C/GTK, and IMHO I think Java's more productive than either (though pre-1.4 X-windows Swing performance was unacceptable).
Sadly, this doesn't seem to be a battle that Java will win on Win32, even with SWT, for a couple of reasons. Microsoft has the industry's talent in developing high-performance Win32 GUI framewords, which will come out for.NET first. WinForms.NET is effectively the next iteration of what was out in Visual J++ 6.0's WFC libraries.
They also have the tools support with Visual Studio. The Java world currently has only *ONE* usable GUI building tool -- JBuilder. And that's not saying much. Eclipse won't have one for some time. The second major problem with Swing (besides performance) was this lack of tools support. I don't forsee a groundswell of tools support for SWT from multiple vendors.
Thirdly, there isn't a whole lot of impetus behind client-side "thick" GUIs in the industry. I don't foresee IBM throwing lots of money at making SWT general-use... the open source community will probably assist in this area, but I'm somewhat skeptical about how much adoption this will generate.
On the bright side, I'm not sure it really "matters". Windows peeps will write stuff with VB like they've always done, the C++'ers will switch to C# (they've really not much choice -- I worked at an MS shop as the Java junkie for 2 years, most C++/Windows programmers there took what MS has given them... there's a lot of shock and dismay when Borland/OWL is on one's resume). The 2nd most widely used GUI framework family will be (gasp) Carbon/Cocoa on Mac OS X. ANd rounding out the list, *nix peeps will continue head-butting between Qt and GTK+ (both of which are still gawdawfully ugly IMHO, quite apparent actually if you run a GTK+ app side-by-side with a Mac OS X application. But I digress).
"I can see them actually introducing more Java extension libraries for other things that Sun did a terrible job on. Collections. Better native threading model. Better I/O model. The list goes on and on."
Whoa, whoa! I disagree with each one of these. We are talking about J2SE 1.4, are we not? I'm quite happy with the collections framework (and I compare this to both stdc++ and the Smalltalk collections library), the java.nio.* package is very sophisticated, and IMHO the threading model is a matter of taste, not stemming from any particular technical disadvantage.
We don't need any more of this - we all just need to learn how to be practical craftsmen that get *work* done.
Sure.
No amount of process will ever make up for proper training, proper documentation, proper version control, and proper testing. Ever.
A process is supposed to precicely about a framework for accomplishing those things. Sadly, it doesn't tell you how to do the work. That requires experience.
If you have good people, set them free.
Depends what you mean by this. Do you mean -- everyone is autonomous, let's hope for emergent organization? Or do you mean -- let's come to a consensus of the MINIMAL required ceremony to get our jobs done in the most effective way possible? The former is possible with a very small team of experts. The latter is possible with a (more likely) team of mixed-expertise(high/medium/low).
What I'm trying to say is that process & methodology doesn't have to be about getting poorly [trained, motivated, disciplined] people to develop great software. It just happens that many poor managers (which are in much larger supply than poor software developers) tend to apply it that way.
Agile processes are precicely supposed to be about letting good people get their job done, without stepping on each other! That's the whole idea behind XP and its ilk.
Object oriented technology, patterns, etc. are all techniques for experienced programmers to create more maintainable and expressive programs by elevating the level of discourse. They can be misused. They don't substitute for experience. But there is value there.
By suggesting that "we don't need none of this extra stuff", you are right -- yet there still is a place for that "extra stuff".
It's kind of like Maslow's hierarchy of needs. At the base levels, you need good [disciplined, competent, motivated, intelligent, trained] people, good team dynamics, good technical management, support from general management.
This is the kind of stuff that the Agile Alliance believes in. People over processes, collaboration over negotation.
At the upper levels of the hierarchy of needs are things like tools, processes, and higher-level programming constructs. They do add a lot of value to software development, but are not first order success-factors.
"However, STRUTS IS NOT THE ANSWER. It is dopey and poorly-designed and has "amateur" written all over it."
I'm saddened your snobbish attitude. You do both yourself AND Tapestry a great disservice.
Struts may not be appropriate for absolutely every class of web applications. But to suggest it is poorly designed by "amateurs" does not reflect the character of Craig MacLanahan, Ted Husted, David Winderfeldt, and many of the other maintainers, all of which are professional software developers with combined decades of experience.
Struts turns web screen flow & actions into potentially reusable state machines. It enables quick validation of forms, tremendous flexbility in how you wish to actually code your application's logic -- in stored procedures, in basic Java procedures, or a fully blown object model.
The popularity of Struts can be attributed to many things
- It's what most projects would write themselves anyway - The source code is extremely clean. - It is very simple - It really helps speed maintenance
For me, Struts is the first embodiment of the potential exhibited by Apple's WebObjects Framework. Struts still has a ways to go to get there, but it's getting there fast. Combined with an object/relational framework, we may finally have in 2003 what WebObjects offered in 1996:D
ASP.NET also exhibits a lot of this potential, and IMHO you can't hope for J2EE to compete with the productivity of ASP.NET without an MVC framework like Struts. I really hope Sun realizes this, fast. JavaServer Faces is long, long over due. And if ADO.NET ObjectSpaces gets released, the Sun may have to stop treating JDO as a second class citzen, fast.
The best explanation of MVC from a "systems" perspective is in Buschmann et al's Pattern Oriented Software Architecture Vol 1: A System of Patterns, which explains "Presentation-Abstraction-Control (PAC)".
The real reason MVC never has been explained the way PARC envisioned it is that no other Smalltalk implementation actually USED pure MVC. Original MVC used to imply that the controller was the code that handled the user input. Eventually this just got embedded into the widgets themselved -- most commercial Smalltalk implementations combined the View and the Controller together.
Now on a larger framework level, the spirit of MVC prevailed but evolved the controller into either a layer of event handlers (the Mediator approach) or a rich declarative binding model (the AspectAdaptor/ApplicationModel approach taken by VisualWorks).
From my perspective, Struts tends to embody the VisualWorks approach pretty well for web applications, with some minor thorny problems intrinsic to web development that haven't really been solved effectively yet: validation, distinction between "client model" and "business object model", and dependencies on the web request-response lifecycle (i.e. scopes of variables are tied to requests or sessions).
For-profits are only as efficient as they need to be, and efficiency, quality, or customer service rarely have any involvement in the success of a corporation.
That's a bit trite, doncha think? Sure, service sucks, qualitiy sucks, etc., but not everywhere. And while sometimes quality player doesn't break out of their niche, quite often they do. It happened with cars. And household appliances.
Do consumers really have no say as to which products sell well? I think they do: www.cluetrain.org
While a genuinely talented and energetic software engineer, he had no comprehension of office politics, chain of command, scheduling, teamwork, etc. He pissed people off, said stupid things in meetings, and failed to deliver when he promised to. No amount of programming talent can make up for that.
Again, this isn't necessarily age, though many politically incorrect people tend to be young. I've worked with and managed people both young and old with this problem. Young'uns tend to be know-it-alls, old coots tend to be seen-it-alls.
Every age group has their childish games. For young geeks, it's the arrogant cowboy-coder "you're a suit!" attitude. You would think people mature with age... but in
my experience childish behaviour in IT organizations also occurs through the political games played by the 50-something techies-turned-managers. The attitude now becomes "You can't take my turf!".
I've worked with recent CS graduates and was shocked to find out that many of them could not even operate an oscilloscope, logic analyzer, or in-circuit emulator! How are you going to debug software if you can't even use basic tools of the trade?
If I was a software developer for embedded equipment, this is expected... but I know of no CS program that has courses for oscilloscopes or logic analyzers unless you specifically take an Elec Engineering minor or option. Usually there's 1 course on digital circuits, and that's about it.
I largely agree with all of the specific points you're making, in what a software developer needs (there's more than knowing C# libraries) -- I just disagree that there's a significant link with age. Of course, I may be singling out the 1 or 2 exceptional young people and the 1 or 2 exceptionaly cranky old people that I've seen.
For most contractors the job is in some city that they don't live in. This means they have to pay for hotels or a temporary living arrangement in that city AND maintain their own house or apt back home. DO the math it's not much take home pay.
Absolutely not. I have been consulting for years, and this is ludicrous. Any consultant expected to go out of town has all-expenses-paid lodging and a sufficient per deim of expenses (usually $60 - $100 a day) ON TOP OF their billing rate.
Merit is merit, it is not distinguished by age. Often you'll find more merit in older people. That does not always hold true -- there are many younger people that have more experience than older people in this industry. There's something to be said for learning capacity, or the ability to allow experience to shape your ideas. This seems to deterioriate (for many) with age.
For example, would a 30-year-old consultant that has been exposed to a variety of clients, target domains, langauges, and technologies not have a certain quality of experience unlike that of the 50-year-old lifelong COBOL programmer?
Similarily, the 50-year-old COBOL programmer may have a different quality of experience than the 30-year old "diverse" consultant. Depth vs. breadth, as they say. But who's to know how much depth a person ever absorbs -- is it not case by case? And which is more valuable -- a mix of depth and breadth, or total depth in 1 area?
Specialization is important, but specialization in several areas may be more appopriate to enable successful projects.
Ah yes, the "if they haven't done it themselves they couldn't possibly teach me anything new" school of thought.
The most optimal ways to approach problems are rarely intuitive. Software engineering needs as much help as it can get, including those who professionally observe the industry's patterns. It's worked in other areas.
All it takes is 1 software lead with the balls to say "no, we're not going to hack". You can create great software on time, and under budget, there are many techniques for doing so and a selection of developers that know how.
In a sense, you're right, things haven't changed in 20 years. In another sense, you're wrong -- things have changed, but many people haven't noticed.
Apple has been noted for trying to take the high ground with the DRM issue. They're not forcing anything down consumer's throats, and make an effort to actually (*gasp*) trust their customers.
I'll admit, the only time I've used DRM to get a 7-day access to a movie on adultdvdempire.com that I was to lazy to wait for on DVD. (hey, at least I'm honest).
Was it worth it? Probably not. I bought it with my Mac, but could not view it with my Mac. I had to use my PC laptop, and it was a tremendous pain to install the Windows Media DRM software on Windows 2000. And I felt dirtier installing the software than actually watching the movie.
With all this hassle, and such limited use of the content, how successful can this model be? Sticking within the same industry, netvideogirls.com manages to have tremendous amounts of content for a reasonable subscription fee, and you always have access to what you downloaded!
When it comes to information, it's an experience good. And the more rights a person has to experience it, the more valuable it is to that person. DRM really seems to miss that. They've also seemed to miss that the rental market (i.e. Blockbuster movies) is REALLY hurting -- people are BUYING movies more than they're renting, for some reason.
On another note, the tone of this article concerns me. It's as if the author was trying to find any bit of mud to throw at Apple in hopes it would stick. Does this make good journalism?
"What does this have to do with XP, and how does forllowing XP help or guarantee this dosent happen?"
I was merely stating what Kent Beck has repeatedly offered as the reason behind XP: it's a means of delivering value constantly, so that when a project getes cancelled, at least *something* valuable is in production. Contrast this to the longer development cycles of other approaches.
"Agility dosent depend on a process, it yet again depends on the people working on it."
My suggestion is that a talented team with a good process will have a greater chance of success than a talented team with no process, or a process that is incongruent with reality.
"The argument about waterfall method is so old that you dont even have to talk about it. This was addressed long, long time ago with the introduction of the OOAD."
I have seen countless OO projects planned under a waterfall methodology. Apparently, you're one of the few that thinks it's been discredited. I don't think it has.
"The ideas OOAD talked about is what Extreme Programming stole and re-branded under their name."
I find this curious. Certainly XP evolved out of the OOAD (Smalltalk) community, but to brand that as "stolen" has a connotation that I don't think is reflective of history. Perhaps you could elaborate.
"Sad, sad, sad. Very sad. I thought you were following logic. Lets analyze your sequence of premises and conclusion.
Premise 1: Success depends on hiring good people. Premise 2: Success depend on a good team. Premise 3: Totally unrelated argument here... about ideas stolen from other places Conclusion: XP is special and good."
Perhaps I haven't articulated my position properly, as this isn't exactly what I intended.
Premise 1: Success depends on management support Premise 2: Success depends on hiring good people Premise 3: Success depends on good team dynamics Premise 4: Success depends on an effective process Premise 5: Processes that promote agility tend to be effective in modern software development. Premise 6: XP in particular is special because it has a unique (and explicit) value system. It has the courage suggest that the most important thing in a software project is to actually deliver simple software through communication and feedback. This kind of value system is sorely lacking in many projects.
Conclusion: I didn't really come to a conclusion, but a stab at one is: many talented teams with good dynamics and management support have still failed to deliver good software because their process wasn't congruent to their task and their environment. XP can help good teams play to win. If you're not a good team, XP won't help you.
"Feedback is needed in any thing, and courage, what the hell does it have to do with XP?"
All of the core values I listed were values that Kent Beck listed in the earliest days of XP's development in 1998, and they are repeated in the first XP book "XP Explained". They are also listed here.
As for valuing courage, Beck's theory is that all methodology and process is based on fear. To actually focus on delivering software instead of documentation and "cover your ass" politics takes courage. If you haven't had to deal with it, tip of the Stetson to you, you're lucky.
"XP is nothing but some good from common sense that people developed, with a few additions of his own that are so stupid. Fololow the common sense for delopment, and you dont need to call it a process."
If it is such common sense, why is there so much resistence to it? And please don't just say "well there's resistence to the stupid elements", because for someone preporting to be logical, you're certainly inserting a very subjective evaluation into your critique.
It seems that every critic of XP dislikes a different aspect of it. I would suggest that individually, an XP practice may seem common sense. What's not common sense is the discpline involved in the way XP proposes each practice, and the articulation/packaging of all 12 practices into a framework where each practice reinforces the other.
XP can work, but it is not a first-order success factor for projects. I would suggest the critical success factors for projects are
a) management support and consistency b) technical competence c) communications competence d) process competence
XP fits into (d). If you're missing ANY of the above 4, which are in order of importance, chances are, you'll only succeed by accident. Sadly, most IT projects are delivered purely by accident.
In detail:
a) XP was created because many projects completely screw up one or more aspects of the above, and Kent Beck was sick of creating software that couldn't be used if the project was cancelled. So, XP is about delivering continuous value. But management (customer) must be consistent, they must speak with one voice, lest you fulfill the wrong goals.
b) Success always, always depends on the people you work with. Surprisingly, often people are very good. Sadly, sometimes they're not. That's hiring, not XP.
c) Team = Product. The quality of your team dynamics and communications are going to reflect the nature of the software that you write.
d) Process provides a framework for agility. It aligns interests and ensures people's needs are being met. Traditional waterfall methods don't do this. Incremental and interative (i.e. agile) methods do do this.
XP is but one of many agile methods, but is also a very special one because of its value system: communication, simplicity, feedback, and courage.
Many projects and companies are politicized and play the CYA (cover your ass) game. They play "not to lose" the game. XP isn't like that - they play to win.
this one would be a reasonable intro, though supplement it with online resources. the 1st book "extreme programming explained" is the manifesto. the 3rd book "extreme programming installed" is the how-to. the 2nd book is details of the planning process..
another book is "Agile Software Development" by alistair cockburn.
Slashdot Mirror
" leveraged buyouts and hostile takeovers , all done on a global scale, were already a century or more of old news before the first shot of the revolution was fired on the green at Lexington."
This isn't entirely true. Large-scale corporations (the size of Hudson Bay or East Indian, which were exceptions) didn't really emerge until the late 1800's.
Another note is the fundamental disconnect in power between management and shareholder. Certainly businesses started with owners that "hired hands" to run the place. But eventually (WW2 and beyond) management rose as a distinct discipline and practice. Management held a tremendous amount of what could be almost called "illegitimate" power.. that is, until the backlash of hostile takeovers of the 1970's and 80's. Hostile takeovers before this time were quite rare... and it's really what started the whole "maximize shareholder value" fad we hear about today -- if you don't keep your stock price up, you'll get raided.
Pyslsk runs fine for me on OS X, but I complied it against XDarwin/GTK... which was a pain, but worked.
I was looking to buy a console this Christmas, and was leaning towards the PS2. I'm not a particular fan of Microsoft, though I'll use their products if they're good (for example, Mac Office 2001). Anyhow, I haven't really kept up with the console market, and XBox Live really was the reason I changed my opinion and picked up an XBox -- my first console since an original NES. I've had a great experience with it these past 3 weeks.
After catching up with the market and playing my new toy, here's a reflection of my rationale for choosing the XBox and XBL:
- I have a cable modem, and I would refuse to use anything but a broadband solution
- I don't want to deal with annoying inconsistencies in multiplayer setup between game titles. XBL has a relatively consistent set of terminology between games.
- I really do appreciate the Microsoft "single source" approach, for now. I don't have a problem paying a nominal monthly fee for a better overall experience (which is what I feel I'm getting thus far).
- The variety of XBL games available is WONDERFUL. I picked up NHL 2K3, Unreal Championship, and MechAssault. (I also grabbed Splinter Cell, which alas is single player, but still great).
- The voice communicator is a nifty add-on, and works relatively well.
As for the quality of games:
- MechAssault is my fav, best experience since MechWarrior 2. It actually has some elements of strategy involved with assault compared to other shoot-em-up's. The single player missions are fun too. Well worth the buy for me -- but I know some friends that don't think much of it because they just don't like the shoot-em-up genre.
- Unreal Championship is tons of fun, just what I would expect if I were playing it on a PC or Mac, though the graphics aren't as good as a high end PC, and sometimes lag gets a bit much
- NHL 2K3 is very rich, graphics aren't as good as EA's but the gameplay is really great. I have a learning curve to get through, unfortuantely.. advanced modes can be tough for newbies to sports games (which I admitedly am)
- and (non-XBL) Splinter Cell is one of the best adventure games on the market right now, IMHO.
What don't I like? Well all in all, the price was rather steep after buying 2 extra controllers, an advanced AV kit, 4 games, XBL, and a console (which had 2 games bundled). That put me back around CDN$800 after taxes. Games run around CDN$70/each at Best Buy. How the hell can parents afford to give this to their kids?
XBox really seems to have been well executed. I have no troubles supporting Microsoft in this product arena, provided they continue to make a great product. It remains to be seen if the market at large will make it a profitable platform, though hopefully it will -- it will keep Sony, Nintendo, et al competitive.
Again, if you think Java's collections libraries are such a dream, you haven't read the code or even understand what is going on.
.... it is still far from what it needs to be... Although, it is far better than what used to exist... it is far from seamless and far from transparent.
Ah, so instead of enumerating rational reasons as to why J2SE Collections are somehow "terrible", you are attacking my expertise which you have no knowledge of. And I never claimed they were "a dream", I suggested I was quite happy with them in general.
"You should check out a few good libraries such as JGL."
I have used JGL since 1996, and it is excellent, quite a lot more features than J2SE collections.
To even compare Java to a Smalltalk collections libraries or stdc++ is pretty shortsighted.
Our disconnect here appears to be in what I'm comparing. You're comparing feature-for-feature. I'm comparing the simplicity and practicality of them. The J2SE collections are very simple, very powerful, and a good "base" collections library. stdc++, JGL, ST libraries are all very "complete" libraries suitable for a myriad of situations, but do not lend themselves well to learning or understanding quickly.
I am certainly not attempting to claim that J2SE collections are a step forward in the evolution of collections -- the point is that they were never intended to be. Why call something terrible if it never aspired to be anything other than simple, relatively powerful (vs. JDK 1.1), and easy to learn?
(regarding J2SE 1.4 I/O)
What does it need to be? Transparent from what? Transparency is not a universal principle. And what seam do you speak of, the unavoidable one between old I/O and new I/O (which is a relatively decent integration at the moment), or another?
Java has no real idea of thread priority.
An unfortunate tradeoff when working in a cross-platform environment. The priority heuristics in the JVM are largely dependent on platform.
Notify/yield/wait is extremely unpredictable with no real guarantee as to what can happen when a thread is notified.
Yield, like priority, is a heuristic hint, for the reasons above. As for notify/wait, they're well specified as to what happens when a thread is notified -- the main problem is the lack of guaranteed fairness. So, it's theoretically impossible to prove fairness in the thread model, again a tradeoff due to platform portability. In practice, most JVM's exhibit probalistic fairness and have relatively sophisticated schedulers.
Note that none of this prevents any JVM from providing their own non-portable APIs for strict priority scheduling or FIFO lock queues. And some of the embedded VMs do provide this, IIRC.
Stopping threads is extremely cumbersome.
Stopping threads arbitrarily is dangerous and I'd really like to understand why there should be an alternative way to do this other than an application-specific mechanism.
Inter-thread communication is difficult.
This is a matter of taste. Communication via shared object state or through other means... which is easier? Depends on the programmer, depends on what you're trying to accomplish. Guarded Wait/Notify is a pretty understandable approach.
I'm not going to go into more details except to say that you may feel that J2SE 1.4 is a gift to the masses, but in reality, there are core issues that still remained unsolved.
It is easy to criticize and call something "terrible" when you don't take into account the goals and priorities of the effort.
I never said J2SE was a gift to the masses and solved all problems. I just disagreed about some of your criticisms, as they seemed to be based on "anything that doesn't meet exactly my need right now sucks" and was completely devoid of the context of the tradeoffs in the features as Sun has implemented them.
Most certainly Sun has made many mistakes: ThreadGroups are ridiculously useless, as are the Java 1.0/1.1 collections, the Java 1.0 event model, taking over 5 years to evolve Swing, not fostering a plethora of look and feels, not giving any real documentation on writing performant Swing programs.
"I do feel that with what IBM is doing, others will follow IBM's lead and develop other extension libraries that are better than the Java core itself. IBM has proved it can be done, and can be done without modifying the core."
In a way, I hope you're right... but I don't think it's the direction the industry is taking.
.NET is one of many things, depending who you talk to in Microsoft's marketing dept. First I'll define that. Forgive me if it's review.
.NET: C#, VB.NET, C++.NET, and JScript.NET. C# is first among equals, but VB.NET can do anything C# can do, again because the CTS/CLS is "the language". .NET just gives you a syntactical skin on top of this abstract language.
.NET good at?
.NET could be seen as the next step in evolving binary interop. I.e. in DOS, it was TSR's and interrupts, in Win 3.1/*nix it was DLL's and pointer-tables, in Win95+/Gnome/KDE it was COM or CORBA components, and in .NET, interop is at the CLASS level. They've basically learned the Java/JAR model of interoperability, then abstracted it to multi-languages (they just call JAR files "assemblies")
.NET makes all languages equal. This was painfully NOT TRUE in COM programming! Almost all of the plumbing underneath COM was to support Visual Basic's interoperability with C/C++ components. .NET levels the playing field here, and people can't pick on VB anymore (other than its cheesy syntax). Anyone can throw an exception in C# and catch it in VB, or define a class in C++ and inherit from it in C#. And debug across all these languages in a single session, if need be. Quite liberating for system architects dealing with a large, multi-team project with reusable components and potentially different skill-sets (hence different languages).
.NET DLL's that are better than traditional Win32 COM DLL's: .NET uses it, sing the praises!
.NET is CHILD'S PLAY compared to some other platforms. Especially with Visual Studio. They've really made distributed interoperability easy -- though of course none of this will scale or be bulletproof without real engineering work, but that's never been Microsoft's game -- let J2EE vendors do the dirty guinea pig work, they'll copy it into Windows/IIS eventually.
.NET really is about making Windows developer's lives A LOT EASIER. Which really was all that Visual J++ 6.0 was about before they decided to "break" features for political reasons. .NET is appropriate as a new standard for dynamic languages like Smalltalk, Lisp, Haskell, ML, etc.
.NET but you have to contort it into classes & methods if you want to interoperate with any other .NET language... this is what the C++ people have to do too! (i.e. no more templates, multiple inheritance, at least until .NET 2.0 :) .NET isn't the second coming, though many Missy-followers think it is because their intranet is locked to http://msdn.microsoft.com and really don't have a lot of exposure to the alternatives out there (i.e. J2EE or perhaps PHP, Python, Ruby, etc.)
Here's the things that it isn't (in reality):
- A new server platform (MIcrosoft marketed it as such, even though there really isn't anything new in their Windows 2000 lines of servers yet).
- A some new magic technology (i.e. the marketing idea that MS Passport became Passport.NET and thus was embued with a +6 long-sword)
Here's what it is:
- The common type system, language spec, and language interface. (CTS, CLS, and CLI). It's a way of getting several languages to interoperate through a virtual machine.
- The Common Language Runtime (CLR) for Win32. This is the Virtual Machine. It's as fast as Java 1.4 in some ways, slower in some ways, and over 2x faster at certain operations like object creation. Ya gatta hand it to Microsoft's x86 team, they know their stuff.
- The following languages are released by Microsoft for
- The Base Class Libraries (BCL), ASP.NET, COM+ (aka Managed Components), and ADO.NET are included.
- The ECMA standards body has been submitted the CLI, CTS, CLS, BCL, and C#. Mainly for show, but maybe something good may come from Miguel et al.
What's
- It's a much better way for binary module interoperability than COM was. Viewed this way,
The language-interop issue at first glance seems like a red herring feature, but in fact it's rather important from a programmer's sociological perspective. VB and C++ programmers are naturally opposed to each other in philosophy - their means and ends do not peacefully coexist.
Things you can do with
- The Windows Registry is NO LONGER NEEDED. Nothing in
- Easy and Flexible Side by side versioning. An app that links against a version stays with that version unless updated or a sysadmin coerces it to use a newer DLL version.
- No filename conflicts (i.e. no 2 vendors with MYSILLYLIBRARY.DLL overwriting each other -- each DLL has a public key stamp)
Other things... Making web services in
So -- you see,
The jury's still out as to whether
I say it's more about "syntax skin" than "flexibility". Certainly you can write Lisp onto
No, I think VB should be cast out into the depths of hell from whenst it was created.
.NET, it is much, much, better than Microsoft's prior technology platform (DNA, "we put the COM in COMplex"). They've created a high quality framework and platform. I wouldn't say it's vastly superior to Java, but it's certainly competitve in some areas (not in others).
But it still is the most popular client-side language in the world.
Regardless of the politcial debates surrounding
"They ignore simple physical facts. like the fact that normal property has natural limits in supply and demand - that imply markets and property law, but that information has no natural limits."
Really? Let's dig a bit deeper, shall we. We'll see this isn't entirely true.
"Information" is an abstract entity, devoid of the human effort surrounding it, so at first glance it doesn't look to be subject to supply and demand.
But on second glance, we recognize that economics is the discipline of applying scarce resources (natural resources, labour, capital, and some might say "knowledge") in the face of unlimited demands. And with regards to information, there really are only two major kinds of demands: distribution & creation.
The cost of distributing information is usually tied to its distribution vessel, its medium. Such mediums typically are physical, and hence, scarce (a mouth uttering words, a diskette carrying software in a shrink-wrapped box, etc.). Thus information distribution is subject to supply & demand, in the general case.
The combination of widespread Internet access and digital representation of information has created a situation where information is "on tap", like water, and hence has effectively a negligable economic value -- though not zero. Why not zero? Well there's that ISP fee, similar to your house's water fee. Another note is that some information requires large pipes -- downloading full DivX movies, for example -- and most people don't have large pipes (yet), and pay a premium for them.
This information/tap water metaphor is making me think of beer, so I'll switch angles and refrain from running to the corner pub.
Ok, so if information distribution has negligable economic value (in theory), we must turn to information creation.
Creating something intangible, like information, is effectively a service. What economic resources are involved in creating information? The traditional resources of the economist -- land and labour aren't really used all that much (capital IS used, but not so much as a "factor" of producing information so much as an "aid") but the "new" central resource of our evolving post-capitalist economy, knowledge (perhaps even talent), certainly is involved. We know very little about the economics of knowledge. But we do know that it has become the central factor of production in any modern economy. And it is central in producing information.
Knowledge, by its very nature, is scarce -- it is not held on a disk, or in a book -- it is held inside your brain. It requires a significant ramp-up time to turn information into knowledge. And there are many bodies of knowledge out there -- many specialities -- that are all required by different people at varying levels of demand. There are different tastes in genres of music, different kinds of software, different genres of movies, and different roles in the creation of all of these works of information -- the credits list of any big-budget movie will attest to the wide variety of knowledge required for making a movie.
So I think it's really clear that there is some kind of scarcity surrounding information creation -- supply/demand exists both in the KIND of information we want created and in the KNOWLEDGE needed to create information. It's the knotty issue of actually setting a marketplace AROUND information that is our problem -- the productization of information is the fallacy that must be overcome.
Some things, like movies, will always have scarce distribution channels like movie theatres to rake in the dough. Music and software will probably require entirely new business models.
One suggestion for a new business model is that perhaps instead of "buying" a CD or piece of software, an artist and/or company will solicit "contributions" to create MORE information. This could work well for music -- the market will support the artists that they wish to make a living at what they do so they can make more music. I'm not sure if this makes sense for software yet, given the higher capital costs to get a product out the door.
I've written quite a few Swing & server-side applications myself.
.NET. And Visual Basic rules on the client Win32 side, and has for quite some time.
.NET first. WinForms.NET is effectively the next iteration of what was out in Visual J++ 6.0's WFC libraries.
"Microsoft and MFC rules on the client side (on Win32)".
MFC is dead, long live
"But now, Java needs to become a viable alternative to C++ based programming on the client-side."
Absolutely not. Java's only main competitor for Win32 client-side supremacy is VB.NET and C#.NET. C++/MFC is a dead-end.
On UNIX, I would suggest it's a toss-up between C++/Qt and C/GTK, and IMHO I think Java's more productive than either (though pre-1.4 X-windows Swing performance was unacceptable).
Sadly, this doesn't seem to be a battle that Java will win on Win32, even with SWT, for a couple of reasons. Microsoft has the industry's talent in developing high-performance Win32 GUI framewords, which will come out for
They also have the tools support with Visual Studio. The Java world currently has only *ONE* usable GUI building tool -- JBuilder. And that's not saying much. Eclipse won't have one for some time. The second major problem with Swing (besides performance) was this lack of tools support. I don't forsee a groundswell of tools support for SWT from multiple vendors.
Thirdly, there isn't a whole lot of impetus behind client-side "thick" GUIs in the industry. I don't foresee IBM throwing lots of money at making SWT general-use... the open source community will probably assist in this area, but I'm somewhat skeptical about how much adoption this will generate.
On the bright side, I'm not sure it really "matters". Windows peeps will write stuff with VB like they've always done, the C++'ers will switch to C# (they've really not much choice -- I worked at an MS shop as the Java junkie for 2 years, most C++/Windows programmers there took what MS has given them... there's a lot of shock and dismay when Borland/OWL is on one's resume). The 2nd most widely used GUI framework family will be (gasp) Carbon/Cocoa on Mac OS X. ANd rounding out the list, *nix peeps will continue head-butting between Qt and GTK+ (both of which are still gawdawfully ugly IMHO, quite apparent actually if you run a GTK+ app side-by-side with a Mac OS X application. But I digress).
"I can see them actually introducing more Java extension libraries for other things that Sun did a terrible job on. Collections. Better native threading model. Better I/O model. The list goes on and on."
Whoa, whoa! I disagree with each one of these. We are talking about J2SE 1.4, are we not? I'm quite happy with the collections framework (and I compare this to both stdc++ and the Smalltalk collections library), the java.nio.* package is very sophisticated, and IMHO the threading model is a matter of taste, not stemming from any particular technical disadvantage.
We don't need any more of this - we all just need to learn how to be practical craftsmen that get *work* done.
Sure.
No amount of process will ever make up for proper training, proper documentation, proper version control, and proper testing. Ever.
A process is supposed to precicely about a framework for accomplishing those things. Sadly, it doesn't tell you how to do the work. That requires experience.
If you have good people, set them free.
Depends what you mean by this. Do you mean -- everyone is autonomous, let's hope for emergent organization? Or do you mean -- let's come to a consensus of the MINIMAL required ceremony to get our jobs done in the most effective way possible? The former is possible with a very small team of experts. The latter is possible with a (more likely) team of mixed-expertise(high/medium/low).
What I'm trying to say is that process & methodology doesn't have to be about getting poorly [trained, motivated, disciplined] people to develop great software. It just happens that many poor managers (which are in much larger supply than poor software developers) tend to apply it that way.
Agile processes are precicely supposed to be about letting good people get their job done, without stepping on each other! That's the whole idea behind XP and its ilk.
Object oriented technology, patterns, etc. are all techniques for experienced programmers to create more maintainable and expressive programs by elevating the level of discourse. They can be misused. They don't substitute for experience. But there is value there.
By suggesting that "we don't need none of this extra stuff", you are right -- yet there still is a place for that "extra stuff".
It's kind of like Maslow's hierarchy of needs. At the base levels, you need good [disciplined, competent, motivated, intelligent, trained] people, good team dynamics, good technical management, support from general management.
This is the kind of stuff that the Agile Alliance believes in. People over processes, collaboration over negotation.
At the upper levels of the hierarchy of needs are things like tools, processes, and higher-level programming constructs. They do add a lot of value to software development, but are not first order success-factors.
"However, STRUTS IS NOT THE ANSWER. It is dopey and poorly-designed and has "amateur" written all over it."
I'm saddened your snobbish attitude. You do both yourself AND Tapestry a great disservice.
Struts may not be appropriate for absolutely every class of web applications. But to suggest it is poorly designed by "amateurs" does not reflect the character of Craig MacLanahan, Ted Husted, David Winderfeldt, and many of the other maintainers, all of which are professional software developers with combined decades of experience.
Struts turns web screen flow & actions into potentially reusable state machines. It enables quick validation of forms, tremendous flexbility in how you wish to actually code your application's logic -- in stored procedures, in basic Java procedures, or a fully blown object model.
:D
The popularity of Struts can be attributed to many things
- It's what most projects would write themselves anyway
- The source code is extremely clean.
- It is very simple
- It really helps speed maintenance
For me, Struts is the first embodiment of the potential exhibited by Apple's WebObjects Framework. Struts still has a ways to go to get there, but it's getting there fast. Combined with an object/relational framework, we may finally have in 2003 what WebObjects offered in 1996
ASP.NET also exhibits a lot of this potential, and IMHO you can't hope for J2EE to compete with the productivity of ASP.NET without an MVC framework like Struts. I really hope Sun realizes this, fast. JavaServer Faces is long, long over due. And if ADO.NET ObjectSpaces gets released, the Sun may have to stop treating JDO as a second class citzen, fast.
Only $25k more expensive :D
The best explanation of MVC from a "systems" perspective is in Buschmann et al's Pattern Oriented Software Architecture Vol 1: A System of Patterns, which explains "Presentation-Abstraction-Control (PAC)".
The real reason MVC never has been explained the way PARC envisioned it is that no other Smalltalk implementation actually USED pure MVC. Original MVC used to imply that the controller was the code that handled the user input. Eventually this just got embedded into the widgets themselved -- most commercial Smalltalk implementations combined the View and the Controller together.
Now on a larger framework level, the spirit of MVC prevailed but evolved the controller into either a layer of event handlers (the Mediator approach) or a rich declarative binding model (the AspectAdaptor/ApplicationModel approach taken by VisualWorks).
From my perspective, Struts tends to embody the VisualWorks approach pretty well for web applications, with some minor thorny problems intrinsic to web development that haven't really been solved effectively yet: validation, distinction between "client model" and "business object model", and dependencies on the web request-response lifecycle (i.e. scopes of variables are tied to requests or sessions).
For-profits are only as efficient as they need to be, and efficiency, quality, or customer service rarely have any involvement in the success of a corporation.
That's a bit trite, doncha think? Sure, service sucks, qualitiy sucks, etc., but not everywhere. And while sometimes quality player doesn't break out of their niche, quite often they do. It happened with cars. And household appliances.
Do consumers really have no say as to which products sell well? I think they do: www.cluetrain.org
While a genuinely talented and energetic software engineer, he had no comprehension of office politics, chain of command, scheduling, teamwork, etc. He pissed people off, said stupid things in meetings, and failed to deliver when he promised to. No amount of programming talent can make up for that.
Again, this isn't necessarily age, though many politically incorrect people tend to be young. I've worked with and managed people both young and old with this problem. Young'uns tend to be know-it-alls, old coots tend to be seen-it-alls.
Every age group has their childish games. For young geeks, it's the arrogant cowboy-coder "you're a suit!" attitude. You would think people mature with age... but in
my experience childish behaviour in IT organizations also occurs through the political games played by the 50-something techies-turned-managers. The attitude now becomes "You can't take my turf!".
I've worked with recent CS graduates and was shocked to find out that many of them could not even operate an oscilloscope, logic analyzer, or in-circuit emulator! How are you going to debug software if you can't even use basic tools of the trade?
If I was a software developer for embedded equipment, this is expected... but I know of no CS program that has courses for oscilloscopes or logic analyzers unless you specifically take an Elec Engineering minor or option. Usually there's 1 course on digital circuits, and that's about it.
I largely agree with all of the specific points you're making, in what a software developer needs (there's more than knowing C# libraries) -- I just disagree that there's a significant link with age. Of course, I may be singling out the 1 or 2 exceptional young people and the 1 or 2 exceptionaly cranky old people that I've seen.
For most contractors the job is in some city that they don't live in. This means they have to pay for hotels or a temporary living arrangement in that city AND maintain their own house or apt back home. DO the math it's not much take home pay.
Absolutely not. I have been consulting for years, and this is ludicrous. Any consultant expected to go out of town has all-expenses-paid lodging and a sufficient per deim of expenses (usually $60 - $100 a day) ON TOP OF their billing rate.
Your assumptions are flawed.
There's a big difference between efficient use of scarce resources (the whole purpose of a for-profit organization) and greed.
One is about entrusting societies productive resources to organizations focused on high performance execution.
The other is about excessive desire for personal gain.
Merit is merit, it is not distinguished by age. Often you'll find more merit in older people. That does not always hold true -- there are many younger people that have more experience than older people in this industry. There's something to be said for learning capacity, or the ability to allow experience to shape your ideas. This seems to deterioriate (for many) with age.
For example, would a 30-year-old consultant that has been exposed to a variety of clients, target domains, langauges, and technologies not have a certain quality of experience unlike that of the 50-year-old lifelong COBOL programmer?
Similarily, the 50-year-old COBOL programmer may have a different quality of experience than the 30-year old "diverse" consultant. Depth vs. breadth, as they say. But who's to know how much depth a person ever absorbs -- is it not case by case? And which is more valuable -- a mix of depth and breadth, or total depth in 1 area?
Specialization is important, but specialization in several areas may be more appopriate to enable successful projects.
Go to www.realrates.com, see what typical independent rates for experienced computer contractors are. Many make more than enough to cover their bases.
The same goes for lawyers, doctors, dentists, etc. that all "one man" practices and make significant ($200k+) revenue.
Ah yes, the "if they haven't done it themselves they couldn't possibly teach me anything new" school of thought.
The most optimal ways to approach problems are rarely intuitive. Software engineering needs as much help as it can get, including those who professionally observe the industry's patterns. It's worked in other areas.
All it takes is 1 software lead with the balls to say "no, we're not going to hack". You can create great software on time, and under budget, there are many techniques for doing so and a selection of developers that know how.
In a sense, you're right, things haven't changed in 20 years. In another sense, you're wrong -- things have changed, but many people haven't noticed.
Apple has been noted for trying to take the high ground with the DRM issue. They're not forcing anything down consumer's throats, and make an effort to actually (*gasp*) trust their customers.
I'll admit, the only time I've used DRM to get a 7-day access to a movie on adultdvdempire.com that I was to lazy to wait for on DVD. (hey, at least I'm honest).
Was it worth it? Probably not. I bought it with my Mac, but could not view it with my Mac. I had to use my PC laptop, and it was a tremendous pain to install the Windows Media DRM software on Windows 2000. And I felt dirtier installing the software than actually watching the movie.
With all this hassle, and such limited use of the content, how successful can this model be? Sticking within the same industry, netvideogirls.com manages to have tremendous amounts of content for a reasonable subscription fee, and you always have access to what you downloaded!
When it comes to information, it's an experience good. And the more rights a person has to experience it, the more valuable it is to that person. DRM really seems to miss that. They've also seemed to miss that the rental market (i.e. Blockbuster movies) is REALLY hurting -- people are BUYING movies more than they're renting, for some reason.
On another note, the tone of this article concerns me. It's as if the author was trying to find any bit of mud to throw at Apple in hopes it would stick. Does this make good journalism?
"What does this have to do with XP, and how does forllowing XP help or guarantee this dosent happen?"
I was merely stating what Kent Beck has repeatedly offered as the reason behind XP: it's a means of delivering value constantly, so that when a project getes cancelled, at least *something* valuable is in production. Contrast this to the longer development cycles of other approaches.
"Agility dosent depend on a process, it yet again depends on the people working on it."
My suggestion is that a talented team with a good process will have a greater chance of success than a talented team with no process, or a process that is incongruent with reality.
"The argument about waterfall method is so old that you dont even have to talk about it. This was addressed long, long time ago with the introduction of the OOAD."
I have seen countless OO projects planned under a waterfall methodology. Apparently, you're one of the few that thinks it's been discredited. I don't think it has.
"The ideas OOAD talked about is what Extreme Programming stole and re-branded under their name."
I find this curious. Certainly XP evolved out of the OOAD (Smalltalk) community, but to brand that as "stolen" has a connotation that I don't think is reflective of history. Perhaps you could elaborate.
"Sad, sad, sad. Very sad. I thought you were following logic. Lets analyze your sequence of premises and conclusion.
Premise 1: Success depends on hiring good people.
Premise 2: Success depend on a good team.
Premise 3: Totally unrelated argument here... about ideas stolen from other places
Conclusion: XP is special and good."
Perhaps I haven't articulated my position properly, as this isn't exactly what I intended.
Premise 1: Success depends on management support
Premise 2: Success depends on hiring good people
Premise 3: Success depends on good team dynamics
Premise 4: Success depends on an effective process
Premise 5: Processes that promote agility tend to be effective in modern software development.
Premise 6: XP in particular is special because it has a unique (and explicit) value system. It has the courage suggest that the most important thing in a software project is to actually deliver simple software through communication and feedback. This kind of value system is sorely lacking in many projects.
Conclusion: I didn't really come to a conclusion, but a stab at one is: many talented teams with good dynamics and management support have still failed to deliver good software because their process wasn't congruent to their task and their environment. XP can help good teams play to win. If you're not a good team, XP won't help you.
"Feedback is needed in any thing, and courage, what the hell does it have to do with XP?"
All of the core values I listed were values that Kent Beck listed in the earliest days of XP's development in 1998, and they are repeated in the first XP book "XP Explained". They are also listed here.
As for valuing courage, Beck's theory is that all methodology and process is based on fear. To actually focus on delivering software instead of documentation and "cover your ass" politics takes courage. If you haven't had to deal with it, tip of the Stetson to you, you're lucky.
"XP is nothing but some good from common sense that people developed, with a few additions of his own that are so stupid. Fololow the common sense for delopment, and you dont need to call it a process."
If it is such common sense, why is there so much resistence to it? And please don't just say "well there's resistence to the stupid elements", because for someone preporting to be logical, you're certainly inserting a very subjective evaluation into your critique.
It seems that every critic of XP dislikes a different aspect of it. I would suggest that individually, an XP practice may seem common sense. What's not common sense is the discpline involved in the way XP proposes each practice, and the articulation/packaging of all 12 practices into a framework where each practice reinforces the other.
XP can work, but it is not a first-order success factor for projects. I would suggest the critical success factors for projects are
a) management support and consistency
b) technical competence
c) communications competence
d) process competence
XP fits into (d). If you're missing ANY of the above 4, which are in order of importance, chances are, you'll only succeed by accident. Sadly, most IT projects are delivered purely by accident.
In detail:
a) XP was created because many projects completely screw up one or more aspects of the above, and Kent Beck was sick of creating software that couldn't be used if the project was cancelled. So, XP is about delivering continuous value. But management (customer) must be consistent, they must speak with one voice, lest you fulfill the wrong goals.
b) Success always, always depends on the people you work with. Surprisingly, often people are very good. Sadly, sometimes they're not. That's hiring, not XP.
c) Team = Product. The quality of your team dynamics and communications are going to reflect the nature of the software that you write.
d) Process provides a framework for agility. It aligns interests and ensures people's needs are being met. Traditional waterfall methods don't do this. Incremental and interative (i.e. agile) methods do do this.
XP is but one of many agile methods, but is also a very special one because of its value system: communication, simplicity, feedback, and courage.
Many projects and companies are politicized and play the CYA (cover your ass) game. They play "not to lose" the game. XP isn't like that - they play to win.
this one would be a reasonable intro, though supplement it with online resources. the 1st book "extreme programming explained" is the manifesto. the 3rd book "extreme programming installed" is the how-to. the 2nd book is details of the planning process..
another book is "Agile Software Development" by alistair cockburn.