I heard the news while driving home Monday night... This is really very good news for Java. The earlier acquisition talks of Sun by IBM would have provided significant resources, but let's face it... IBM began as a hardware company (as did Sun). Oracle is and always has been a software company, and a very effective one. With Sun, Oracle acquires a great Operating System (Solaris) and it assumes the stewardship of Java. I'm very optimistic that Oracle's going to know exactly what to do with these software assets... something that hardware companies never do seem to get quite right. Update I think that Cay Horstmann's pronouncements are fairly reasonable... but we have to also keep in mind the larger context - Oracle acquires lots of companies, and in many respects Sun is just one more. Oracle will keep the things that increase software revenue, and they will keep the things that build and maintain professional developer loyalty - I've been to many Oracle developer events, and they always go all out to make professional developers feel appreciated. Oracle's biggest challenge is to make sense of all of its acquisitions... particularly BEA and Sun. I have to agree with earlier posters that Solaris is the one thing that will absolutely make the cut - A great Operating System is the only thing that Oracle did not have (apologies to Linux fans, but it's just not the same). I'm not sure about the revenue potential from Solaris, but think of the marketing message: Oracle has it all. I maintain my pronouncement that this is a good thing for Java in the long run... All these questions between really Open and sort of Open are out in the Open. No bucks, no Buck Rogers - Projects like Glassfish and Netbeans can't be great unless somebody is underwriting the huge cost of making and keeping them great. Sun was wonderful for providing that underwriting, but it's doubtful if they could have continued. Alternate funding would have been necessary... Oracle's actions just make us think about that sooner.
If you are a Developer who builds sites where folks go to "do things", then I hope can inspire you to think a bit about those "things" as part of a larger Process. It's not a huge leap to build into your site the hooks that a Process Guy like me needs to incorporate your site into a larger Managed Process. I'll be grateful if you make the effort, and I'll bet the users of your site will be too. Please check out the details on my other blog.
Rumor has it that IBM is buying Java - and the company that spawned it. Of course I'm exaggerating- Sun's more than just Java - but I bet Java is the key. IBM has made huge investments over the years that are dependent on Java, and the prospect of anyone else getting hold of Java has got to keep many IBM execs up at night. Will this be a good thing for Java? I think so. Open Source software may be free, but developing it sure isn't, and having a financially sound landlord is a good thing. If this truly is the end for Sun, that's a sad thing. But it's not necessarily a sad thing for Java.
Chris Adamson recently questioned the value of Swing 2 and I have to go one further... Isn't it time to admit that the Desktop is dead? I think that it's pretty clear that GWTpoints to the future and "Swing 2" clings to the past. Marc Andreessenwas a bit premature when he said something like "The Browser is the Operating System" back in the 90's, but it's clear that his prediction is coming to pass... Take a look at Chrome's features for a hint of what's just around the corner. With Browser Applications like ThinkFree,Zoho and Google Docs getting better all the time, and with SmartPhones (with betterBrowsers) andNetBooks becoming pervasive it's best to not waste any more time on the Desktop paradigm. Update:All - The responses to this post are almost unanimous. Those of you who left your comments are a pretty passionate lot... Responses seem to make two major points-
Desktop Apps are and will always be "richer" than Browser Apps
Browser Apps make things too easy for Big Brother to spy on you
Thanks to everyone who responded... One commenter asked "What was the point of this entry?" Your comments are the point of this entry. I love it when you state your positions, justify your positions, and offer your own opinions. It's much more fun (and productive) than sitting back and assuming that everyone agrees with you. As for the fate of the Desktop... We'll find out ;-)
One subtext of this discussion raises a wider question - When is it "Programming" and when is it "Software Engineering"?
I'm not sure that the distinction really matters... it's kind of like trying to nail down a definition for "Scripting Languages" rather than "Real" programming languages... but I'd like to share my thoughts.
I think that it's Software Engineering when your primary focus is on the relationships and interactions between software components. Programming is when your primary focus is on implementing specific requirements.
I know that's a pretty mushy distinction, but it's the best I can come up with for now...
To build on this distinction a bit more: It is my very strong belief that everyone should be taught how to Program. Reading, Writing, and Arithmetic just aren't enough for the 21st Century - Everybody should be able to write simple programs.
In contrast, Software Engineering is a very specialized field and way beyond the needs of most people. Like Electrical, Mechanical, Civil and the other Engineering disciplines, it takes years of preparation to master. In my experience all Engineering boils down to math and metrics (How else can you measure the effectiveness of an algorithm?).
Bringing ths back to the BPM/Software Engineering discussion going on at InfoQ... I agree that BPM is not Software Engineering (it's more akin to Process Engineering). There's a huge amount of Software Engineering that goes into building a BPM suite, but that doesn't generally concern those who are actually using those suites.
When implementing a Managed Business Process you must employ good Programming skills - but in most cases you are building within the dictates of your BPM suite's Software Architecture. To me that's not really Software Engineering, it's Programming.
From where I was standing at the time I'd have to say Object Oriented Methodology. Our practical experience with software led us to value encapsulation, inheritance and polymorphism - but we didn't have to tools to enforce those concepts in our code. End result: We knew how to write good code but it was awfully hard. We had to hand-craft coding conventions that Object Oriented Languages gave us for free.
Object Oriented Languages led to a Renaissance in programming... The tools codified the methodology - leading to unquestioned validation of the methodology - leading to wide adoption of the methodology. Said another way: Most programmers began to think in terms of Objects.
Methodology by itself probably would not have led most programmers to think in terms of Objects. Languages by themselves probably would not have led most programmers to think in terms of Objects - If you don't believe me go back and look at most of theC++ code that was written in the early 90s (most programmers continued thinkin inCfor several years).
Object Oriented Design and Object Oriented Languages have been a huge factor in my programming career - but they aren't enough. Objects are just a subset of what I need to solve the problems that I have been asked to solve. I deal with Processes and I deal with Services.
Processes and Services are hand in glove - Processes Orchestrate and Choreograph Services - so any good Process Tool has got to also be a good Service Tool.
There are some really good Process and Service Tools out there - but they're mostly proprietary (expensive). Those of use who are fortunate enough to use them have really been able to immerse ourselves in the methodologies - We think in Processes and Services.
Most of the widely available Process and Service Tools feel a lot like C++ to me... They're Object Oriented environments that have "just enough" Process and Service tacked on to be useful - Many folks who use these tools still mostly think in Objects.
It's hard for me to convey exactly what I am talking about - unless you yourself think in Processes and Services you probably won't grok the nuances that make them powerful - but here's a stab at something that you might be familiar with.
The Spring Framework has a very good component (Spring Web Flow) for controlling the flow between web pages that are presented to a user. If you're a Process guy like me, this is a wonderful little subset of what's available via BPMN. You are essentially modelling a Process with a single participant as they navigate through a series of screens.
Unfortunately, the IDEs that support Spring Web Flow pretty much shuffle it off to the side. They encourage good old OOD with this funky little XML thingy that you use to govern page flow.
A Process Oriented IDE would turn this paradigm on its head - When you started a new project you would begin with the Web Flow. Your Pages would begin life as stubs with just enough functionality to set the data the Flow Controller needs to get to the next Page. Instead of a "folder tree view" of class hierarchies, you'd find the elements of your project by drilling down through the Flow diagram to the Pages and the underlying Services (objects) that support those Pages.
What I've described is pretty much what you'll find in the top-tier BPM products... Use these tools and you'll quickly start thinking in Processes and Services.
Once again this reminds me of the early days of OO - Smalltalk was impractical for most of us, so we had to make due with C++. The mainstream programming tools were still procedural (rather than object) in flavor... but in just a few years the critical mass of programmers started thinking in Objects. The rest is history.
My guess is that Process Methodology and Tools are at about the same point where OO Methodology and Tools were in the early 90s... What do you think?
Back when I was working on Tandy's DeskMate we were trying to build a personal computer "that Mom could use". I think we came pretty close to that goal... Mom could use it. Unfortunately Mom didn't want to use it :-(
Fast forward to today, and I am firmly entrenched in the wonderful world of Business Software Development Tools. I'm not so much interested in building software for businesses as I am in enabling businesses to build their own software - or at least play a much larger role in building that software.
On aspect of enabling business dudes is BPMN - Business Analysts and Programmers using this shared notation to carry on discussions. BPMN is pretty good, and reasonably easy to learn - When used properly it does embower business dudes without pissing off the programmers (too much).
Unfortunately, a Process Definition just isn't enough. It's important, but at best it's only half of the solution - You've got to define the Data too.
Chris's thoughts helped me boil down my premise to a single statement:
Programmers should understand the applications that they are writing.
You might think everyone would agree with that statement... but you'd be wrong. Go look at the comments on Chris's blog. My favorite is the following from James Browning:
"It's a lot easier for a typical developer to know if their IDE is useful than if they're building an accounting package"
Which is s good reason why the proposed methodology has limited use. I am currently on a contract in an insurance underwriters. I am working on their accounting package and for me to understand everything about how the software is to be used and why I would basically need a degree in accountancy.
That's why we have business analysts ;-)
James has a point, of course. Most programmers will never understand everything about how a particular application will be used... But surely they should understand something about how the software is used. If not, then programmers really are interchangeable cogs and we all deserve to have our jobs outsourced.
So what's the minimum? When do you know "just enough (about the business) to not be dangerous"?
The same is true for Business people. It's very important for the Business Analysts (that specify software) to know "just enough (about software) to not be dangerous".
Those of you who are sick of my blogs on Process Driven Design should stop reading now... I'm about to make my same old pitch...
Business analysts and programmers need a common language. Programmers need "something to read" that tells them how the business works. Business analysts (who specify software) need "something to read" that tells them how the software works.
Business analysts don't need to know all of the aspects of the software, and programmers don't need to know all of the aspects of business... but both sides need to understand the common middle ground.
If you follow my blogging it will come as no surprise that I think that BPMN is a great way of describing that common ground. The business analysts draw the boxes and connect the lines - the programmers implement all the little details that make those boxes actually work.
BPMN is evolving, and there's a raging debate on just how expressive BPMN should become. Should BPMN just describe the highest level details of a process, or should you be able to precisely express a lot of details? I tend to agree with Tom Baeyens's views... BPMN should stick to modelling and steer clear of execution sematics.
Regardless... I know from experience that (some) business analysts can learn to "think" in BPMN. I know from experience that (some) programmers can learn to "think" in BPMN. I know from experience that if you combine a BPMN literate business analyst with a BPMN literate programmer you will probably end up with a kick-ass managed business process.
One of the best jobs that I ever had was back in the mid-80's working for Scott Cutler at Tandy Electronics Research and Development. I worked on the team that built the DeskMate II GUI shell and its associated applications. This was back in the glory days when many vendors were still pushing their own graphical environments - Apple clearly in the lead - Windows not yet quite measuring up - Atari and Digital Research's GEM still viable contenders.
We wrote everything in C and 8086 assembler... Life before objects: Smalltalk was around but too much of a resource hog for the Tandy 1000 (256K of RAM and a 5 1/4" floppy). C++ was just a rumor as far as we were concerned... Structured programming was king.
Our development methodology was simple but effective... the marketing group wrote the deskmate user manual and we built the applications to match the manual. To be more precise, the marketing group would write a proposed manual, we'd negotiate with them over what could and what couldn't be done, and then we'd build to the manual.
I guess you could call this User Manual Driven Development, and I think that it still can be a very valid approach. In most respects User Manual Driven Development is very close in spirit toTest Driven Development - The function of the software is clearly defined, so it's very clear if the software doesn't do what it is supposed to.
Some time between the 80's and now we mostly abandoned the idea of User Manuals. Let's face it... few users ever bothered to read the manual (Leading to the ever present RTFM reply on many support forums). Few companies even bother much with online help... Users are mostly encouraged to just play with the software and learn by doing.
I'm not advocating a return to User Manuals... but I do advocate tailoring our development methodologies to return the programmers focus back to the users. The prime objective is always to satisfy the needs of the users... The users really don't care about object hierarchies, they don't care about Java vs. Ruby. They care about being able to do what they need to do.
I think most of you will agree that some of the best software that you can find is software that is primarily used by programmers. Eclipse, NetBeans,Visual Studio... This comes as no surprise: Programmers understand the needs of other programmers. Since I understand the purpose of the software, and I know how I would like it to work, then I am extremely qualified and motivated to develop the application.
It always stuns me when I encounter an engineering manager who believes that his staff doesn't need to know how to use the product that they are developing. I've heard people say "Just give us the requirements an we'll build it". I simply cannot agree with this philosophy... Requirements are never enough. Ever.
To write great software, you have to put yourself in the shoes of the user and walk a few miles. Perhaps it's a bit like method acting... Unless you "become" the user you're just going through the motions.
My friend Bob was troubled when I blogged "Object Only Programming is Silly". Bob knows from experience that life after OO is dramatically better than life was before OO... so my criticisms just don't sit well with him. Obviously I must have gone off the deep end :-) If you're interested in Bob's thoughts and my reply, check out my ramblings: Another look at Object Oriented versus Process Driven Design.
Is Programming hard... or are we making programming hard? That thought came to mind while I was reading Johan Den Haan's well stated opinions on Reasons Why Model-Driven Approaches (will) Fail over at Info Q. He's not saying that MDA won't work, just that it's not the be-all and end-all to solve all of the headaches of programming. I mostly agree with Johan's opinions about MDA... in my lexicon MDA is synonymous with UML(which Martin Fowler's christened as the Unwanted Modelling Language) and modelling objects just hasn't been the central problem on any of the programming projects that I've ever worked on. My problems have always related to Requirements. Programming is the craft of transforming requirements into something that a computer can execute. Let me say that again: Programming is the craft of transforming requirements into something that a computer can execute. Over the years there's been exponential growth in the things "that a computer can execute". Back when I started programming OCR(recognizing text) was still a major technical hurdle... now you find it in hand-held devices. What hasn't progressed as quickly is the "other" part of my programming equation: Transforming Requirements. It's often extremely difficult to follow the trail from a Customer's Requirement to the Programmer's Code that implements that requirement. MDA is an attempt to solve that problem... the idea being that a Model is a more recognizable expression of the Requirements than several hundred lines of code. The "map" from the Requirements to the Model ought to be pretty simple. My problem with MDA stems from a disagreement over what to model... In my opinion a Process Models is a clearer representation of Requirements than an Object Model is. Regardless, I think Models are a Good Thing. Improving the mapping from Requirements to Code can certainly make programming easier, but the fundamental problem remains: Requirements. If you don't have the Right Requirements (or they are ambiguous, vague, or self-contradictory) then programmng is probably going to be a nightmare. This is where the "we" in my original question "are wemaking it hard?" comes from. John Wood wrote a great blog entry from a typical programmer's view of what makes programming hard... but I think he missed something important.... We seem to regularly block our customers (those who dictate Requirements) attempts to understand what the heck we are doing. We don't want them checking our work until we are done. Said another way, we often block cutomers attempts to validate the requirements that they gave us. We do this in subtle and perhaps unintentional ways (and in not-so-subtle and blatantly in-your-face ways)... sometimes hinting that "what we do" is more important than "what they do", and mumbling that "they wouldn't it understand anyway". So how does blocking customer inspection of our work make programming hard? It all goes back to those darn Requirements. I think that many of our problems are caused by focussing (obsessing) on the wrong things. We get sucked in by those nifty techno-glitches that pop up all over the place... and sometimes ignore the very features that the customers really need. We all know that what customers really need isn't the same as what they want... but that's another blog. I think the way to programming nirvana is to aggressively pursue techniques that more closely align Requirements to Implementations. If we have a better idea how (and if) we've implemented what they want, then I think we'll stay focused on the right things. I don't think this is impossible... in fact I think we're already moving in the right directions:
Process Modelling and Execution Environments (BPM)
We need to stop focussing on tools that are purely developer focussed, and start focussing on tools that foster communication between the developers and the SMEs (Subject Matter Experts). We need to integrate tools that let the SMEs implement what they can with the tools that let prgrammers do what they must (let's face it, we know how to do things that they don't need to know how to do).
Yeah... Programming is hard... But it doesn't have to be as hard as it is.
Fill in the blank in the following statement: Most Software Development Obstacles are ______ (A) Technical (B) Cultural If you answered (A), then I am intensely jealous :-) When I became a programmer, my answer definitely would have been (A) and I probably wouldn't have had a clue why (B) was even on the list. I doubt that I had any idea what "Cultural Obstacle" even meant in the context of Software Development. I was drawn to programming because of the technical challenges (I love solving puzzles and building things). My University classes (except for electives) all of the classes that I took at the University were concerned with Science and Engineering. Now I realize that I should have taken some basic classes on Psychology. Let me give you one example: The implementation methodology that I practice and the one that I encourage others to practice can be expressed pretty simply:
Build "something that works" and start using it. Identify the next most iimportant thing to extend or enhance and then build and use that thing. Continue these cycles until everything is "good enough".
I now call this "iterative development"... but I use to call it "the shaft of light theory". Others might call it Agile. I arrived at this approach pretty early in my career... as I think many of us do. I found myself working on overly ambitious projects that just seemed to drag on and on with no end in sight. Nobody knew what worked and what didn't. Everything on the project plan was 80 percent complete. As deadlines approached we'd start dumping feature right and left until we got down to the stuff we could actually finish by the due date. On top of that we'd often "finish" only to find that the output of our labors wasn't what the end user really wanted. Perhaps we had misunderstood or perhaps they had changed their minds. Regardless, nobody was happy despite our hard work. I am a huge fan of "play backs"... Demonstrate the application to the users as you develop it to insure that what you are building is what they need. Often the requirements will change as the users become fully aware of what (you think) they asked for... and that's okay with me. Admittedly, this approach won't work for everything... but for the jobs that I do (where there's a lot of human interactions) it works most of the time. Most of the Quality Assurance people that I know hate my approach. How can they assure the Quality of the product if the requirements are in flux? Look at QAs objections from a process perspective: one measure of a good process is the amount of necessary rework - less rework is good, more rework is bad. From a QA perspective iterative development is bad because it requires them to do a lot of rework - testing "the same" functionality over and over. Prior to a production deployment everything must be tested, and in many cases even regression testing is foiled by new requirements. From my perspective this is a small price to pay... It's more important to get "something" to the user as early as possible, and we're much more likely to build what they really need. I have to admit that QA has a point though... Without a comprehensive plan from day one... How can you reliably estimate when you'll be done? I've focused on QA and Development - but you know the same applies to Security, DB and Network Admins, etc. Each have their own jobs to do and their own ideas on how to do their jobs well. There are no right answers here... It's a clash of cultures rather than a question of technical merit.
"Measure twice and cut once" versus "Shave off a little and see if it fits".
Both approaches "work"... But they don't work together. What's crucial is for each organization to develop a culture that works for them. If you hire an Agile Development Manager then you'd better hire an Agile QA manager. Some might argue that it's good to have divergent viewpoints within an organization, but my experience has taught me that everyone is much happier (and everything works smoother) if the department heads agree on the fundamentals. I don't agree with executives who believe that underlings who fight with each other produce better results. So what do you do when you find yourself working with others who disagree with your approach? What do you do when you disagree with their approach? My guess is that you've already dealt with these questions many times... sometimes with positive outcomes and sometimes with negative outcomes. Hopefully your positive outcomes are on an upward trend... If not it may be a good time to reflect on "life, the universe and everything" and adopt a more effective approach for dealing with others. They may be morons. They may be idiots. They may even be slackers and lazy. But I doubt it. They probably just belong to a different culture than yours. If you want to be an effective programmer, you are going to have to find a way of dealing with them - or your efforts will be wasted... Welcome to the wonderfuil world of programming ;-)