 |
|
An Interview with Danny Sabbah
AW: We had such a fruitful interview with Steve Mills a few months ago, we decided that more interviews for this blog might be in order. We were lucky enough to spend time with Danny Sabbah, the General Manager of Rational. (We also interviewed Eclipse guru Erich Gamma and we’ll be posting his interview on this blog soon.)
Of course, all of my questions to Danny have to do with software development issues – especially with how the development of software is changing and how that change is allowing it to support business organizations differently now and into the future more than it did in the past.
AW: When we met at the SWG (IBM Software Group) Briefing recently, you said that geographically distributed development was really about open supply chains. Can you talk about that? Does IBM use that kind of development itself? Do you support it for customers? What are the pros and cons?
DS: Think about teams in different geographies. In today’s world it’s all about leveraging globalization to build new types of products or to build the same products in new ways to achieve greater cost efficiency. Many of these products require the integration of elements from different companies [coming from widely distributed geographies]...
If I’m in telecomm and I want to build out a network of switches or if I’m at Nortel and I build a new switch, I have to take into account all the elements of a supply chain, from sand and iron up. I have to actually assemble everything along the way into a product for a particular market. A lot of that includes the integration of software as well as hardware. There are suppliers who give me elements of the software that I assemble into a product for a Verizon or a Cablevision as [I build] an integration product.
What’s happened is that it’s not just a matter of putting together different elements from different suppliers, but those suppliers are putting together software that runs their piece of the infrastructure. So each vendor’s development piece stretches from his work to other’s elements and the development platform needs to support everyone. It’s distributed teams but not distributed teams in one enterprise and it’s not distributing parts of the work – it’s integration with a large part of the value coming from software.
Distributed Development at IBM
For IBM’s business it has tremendous impact. I’ll give you a vision of where we should be, but it’s not where we are. What I’m trying to do with Rational is to turn it into a platform that lets people do it in a much more systemic way. The stumbling and bumbling is “I want WebSphere to play in this ISV role” or “I want this ISV to use WebSphere in this context” so WebSphere needs to take in requirements not just for the market but also for the ISVs. One of the things we envision for the future is that the ecosystem becomes a development management pool. You can open up broader pieces of WebSphere to that development community and they can contribute to its ongoing development in a collaborative community. They can have much more feedback on what’s going on in a particular piece of software.
If you look at my next generation piece of software [at Rational], that’s what I’m trying to do with some of the people on my board of advisors. I’d like to set up that kind of collaborative engineering effort where they’d help guide the effort – a collaborative platform in a collaborative process.
AW: On a number of occasions we’ve discussed how the hottest software of one time period gets superseded five or ten years later by something else and becomes – well – not so hot. You said recently that’s because we’re always looking for more granularity. Is that an endless search? How are we going to achieve more granularity as we move from current systems to SOA and what benefits will we achieve in the process?
DS: Sort of “Yes,” – it’s yes and no. It’s a little more subtle and complicated. It’s not granularity but modularity. What happens is that every generation is a compromise. When we did OO [Object Orientation], within the first 5 to 10 years no one was using it – Performance [was the issue]. Moore‘s law had not caught up to that level of performance and modularity. That is, you need enough memory and speed to deal with the indirection and transitions between pieces of code. Every time you increase the granularity you increase the number of transitions. One answer is raw speed – the other answer is compiling. In the early days of Java, we used frameworks (putting objects together) and Just In Time compilers to compile out some of the modularity to get acceptable performance.
Every time you go through a shift in modularity to get more flexibility the cost is performance. The reason we didn’t do SOA 15 years ago is that we didn’t have the overall performance to send messages, do processing, and turn a document into an actual execution. It’s not that the ideas or the granularity is foreign, but rather that the systems weren’t ready. We used EDI because the language was ready for a more specialized optimization – but it doesn’t have generalized applicability for generic systems.
With the advent of the Internet, the investments that made connectivity cheap and global, expressing messages from one program to another became possible.
The Question to ask is “Have we finished?”
The question to ask yourself is “Have we finished?” The only way to ask that is whether the degree of flexibility on supply chains is enough. That would be true only if the business models don’t shift. I doubt that. You have one generation of business models and process models captured in R3. SAP will happily tell you that SAP is based on an OO language that defined an enterprise 15 years ago. It let companies go horizontal within their own enterprise. They couldn’t do it themselves, so they bought a common business model from SAP. But today our idea of a business model spans more than a single enterprise so it’s no longer able to deal with the new business model, on the Internet, with new standards. That notion of modularity will continue to shift as business models shift.
It’s a virtuous cycle. The improvements around Moore’s law, Metcalfe’s law, enable new business models, new automation, that cut costs, and enable globalization. More sophisticated business models then required ever more sophisticated technology. Get past a tipping point and everyone wants to jump on. There’s no isolated causality – just two ideas each acting on each other.
AW: I am intrigued by your comment that software architecture evolves to fit the changes in organizational structure. I have a picture in my mind of their moving, side by side, into a sunny future. Can you explain how that happens? Is it just a pleasant coincidence? Or does organizational structure demand a particular style of software architecture?
DS: Not steps – a series of cycles – you jump from one to another over time. Once you jump on a bandwagon, you play it out, which takes 5 to15 years, depending on the industry – service industries shift faster than hard goods industries. Physical assets are harder to change.
I would agree that customers think technology enables changes in the business process rather than changes in the business requiring changes in the technology. They have a blind spot because they don’t really understand technology. The notion that modularity reinvents itself – it’s not brand new.
AW: For SOA to work – especially using the Rational Tools I’ve seen – someone has to write the software that allows non-programmers (business professionals, I guess) to select choices from a palette and have the software spring into existence. Who’s going to do that? What happens when the business professionals want to do something that isn’t on the palette? Is it a jump off the cliff situation like all the 3GL/4GL tools have always been?
DS: The absolute answer is there’s going to be a cliff. But every generation gets more domain specific and more flexible within its domain. The functions made available to the business professional are richer and you can do a lot more, faster. Can you do everything faster? No. There will always be room for corner conditions that were not considered when building out the palette conditions for you -- or the functions on the palette may not be suitable. One of the easiest places where you see this happen is in building a relationship. If you want to integrate with a business partner, I want to show him only what makes him successful and nothing else... I don’t want to make him belong to my company as an employee – which was what we did in the past. I want to open the system and reshape it and reshape the business processes around it so that his access is limited.
When a clerk at a bank accesses information about my account at a bank they may or may not get all the information I get at my HTML browser at home. But the system has to be able to provide all of the information, interacting with security. Any time I increase the granularity I have to rethink all the business processes around that level of granularity – change them. To the extent that I’ve designed well and the interfaces that allow them to be implemented are easy, business professionals can do that. To the extent that I did that by violating rules I’ll fall off the cliff. It’s an argument for standards. These may be industry legislated or domain legislated (not government legislated). To the extent that they are followed you have more flexibility. But there will always be corner conditions where you fall off the cliff and you’re back in the world of creating new palette elements, rearchitecting new infrastructure – beyond the ability of the average business analyst.
AW: You’ve been talking a lot recently about the business process of software development and the governance of that process. Just thinking about programmers fitting into a business process makes me giggle. What do you have in mind and how will it work?
DS: The culture around software developers is not conducive to being governed. There are a number of ways to make this work. Some of it will happen anyway because of compliance. When a company is forced to prove during a SOX Audit that the automation of the accounting system works, you’re in trouble. So some of it is happening. When you’re trying to get FDA certification you have to pass the audits, so the whack jobs who say “leave me alone I am a creative artist I will write the algorithms that will make you successful” [can’t be accommodated]. All of a sudden people get fired if they can’t fit the mold – or the CEO ends up in an orange jumpsuit. If it’s the CEO or the programmers using tools, there’s no question of what’s going to happen. This is real.
To counterbalance that, we make the tools as unobtrusive and as usable as possible by providing them with underlying capability that automatically monitors what they do. It doesn’t require their [the programmers] time or energy to establish the records for traceability or auditability. If you can satisfy both sides and let the creative energies be used and yet the compliance to be established you have solved both problems and made both groups happy.
The same forces always exist – [there is no] magic solution to the problem of disruptive compliance – but it’s forcing us in the direction of allowing this kind of monitoring without intrusion on the creative process. There are other global forces at work here. If the developers don’t understand the importance of some degree of discipline, there are others (outsourcing) who do. They document and test everything. They’re hungrier and not as arrogant around that set of capabilities. They say “You want me to document it’ I’ll document it and I’ll do it for less.” So what’s happening, is whether we do it through tools or through cultural shifts, it’s happening. People won’t want their job to be outsourced. They’ll trade some freedom, so their job doesn’t go elsewhere.
Don’t forget the notion of monitoring. It’s not just compliance it’s also information about where you are in the process of developing so that you can react to and develop better.
From an interview with Danny Sabbah, General Manager of IBM’s Rational, on 12-22-05.
Note that we’ve used the convention of putting Danny’s own words in regular typeface and my questions, comments, and additions in italics.
Mar 09 2006, 01:40:00 PM EST
Permalink
|
|
An Interview with Erich Gamma
What do you do?
I’m an IBM Distinguished Engineer at IBM Rational Software and I’m one of the leaders of the Eclipse platform project. My team in Zurich is involved in Eclipse but we also work on new IBM Rational team products. I’m probably best known as a member of the Gang of Four, which is known for the book: "Design Patterns - Elements of Reusable Object-Oriented Software". I have paired with Kent Beck to develop JUnit, the de facto testing tool for Java. We have just recently released JUnit4. I’ve also paired with Kent Beck to write the book "Contributing to Eclipse: Principles, Patterns, and Plug-ins".
Why should someone change their development model and move over to Eclipse? What’s the reward for the investment in time and skills-building? Will I write better code? Better applications? (I’m never sure they’re the same thing.) Will I be worth more money in the programming marketplace?
There are different ways to leverage Eclipse - you can use it as your development tool or you can use it as a platform to develop your own rich client applications.
I’ve divided Erich’s answers into three segments, Development Tool, Application Platform, Better Applications.
Development Tool
If you use Eclipse as your development tool for Java then you will get the tooling that will make you more productive. The Eclipse Java Development Tools codify proven agile practices like incremental design with refactoring, continuous testing with integrated unit testing support, and immediate feedback about your code. In addition, the extensibility of Eclipse invites you to be your own tool smith and create additional custom tools as plug-ins.
Application Platform
Since version 3.0 you can also leverage Eclipse to build client applications with rich functionality. This is referred to as the Eclipse RCP [rich client platform]. RCP is a subset of Eclipse which separates the development tool specific pieces from functionality that can be used in any client application.
It’s hard to say if you’ll write better code but you’ll have to write much less code because you don’t have to write all of the standard stuff (which you can reuse or extend). NASA has an Eclipse RCP application for managing space exploration data [Maestro: http://mars.telascience.org/home]. The feedback we heard from the NASA development team was that they could throw away lots of their custom code when they moved over to Eclipse. Obviously this does not come for free – there is a learning curve. You have to find your way through the Eclipse APIs and frameworks. Fortunately, Eclipse comes with the source code. This means that when you’re learning Eclipse or implementing your application, you can guide yourself by example with the code that comes from the Eclipse developers.
Eclipse also comes with tools that help you develop plug-ins [plug-in development environment PDE]. Our goal with these tools was to provide you with a fast track to plug-in development. After you have installed Eclipse you should have your first plug-in running in a couple of minutes.
Better Applications
Given that you can reuse tested code, can see some good examples and you have to write less code, the quality of the applications will be better. As Eclipse evolves and improves, your application will also benefit from these improvements.
When building on top of RCP you also build on top of the proven and scalable Eclipse component model which based on plug-ins. The component model helps you to make your application both more modular and more extensible. The Eclipse component model itself is built on top of the OSGi service platform.
How long does a programming model last? Isn’t any programming model just one more (hopefully improved) waystation along the road? In our conversations, Danny Sabbah and I have guessed that a new one comes along as the mainstream about every 5-10 years.
As developers, we just have to accept as fact that there will always be new programming models. The programming model defines the abstractions and concepts developers build and need to use. Eclipse defines a programming model for rich client applications. Its key elements are the plug-in support and the published APIs. When building Eclipse we were thinking of building something that lasts at least 10 years - or even longer.
We refer to this mindset as Build to Last. A major focus of this mindset is API stability. This is very important to us. While we continually improve we always keep an eye on not breaking existing clients – Build to Last or be forgotten quickly.
How does AJAX fit into the Eclipse model? Is AJAX really something new? I went to an AJAX briefing recently (at a Java Users’ Group) and I thought (and some of my fellow attendees agreed) that it didn’t let you do anything new; it just provided you with a somewhat easier way to do it.
You can look at this from the tools and from the application platform angle.
Tools
AJAX is a grouping of existing technology – not something new. Developing with AJAX isn’t “easy” – it is a mix of different technologies that a developer has to juggle. Getting productive with AJAX requires both toolkits and tools. [Note: We’re beginning to see a few]. I wouldn’t be surprised if there was a proposal to add AJAX support to Eclipse [in fact this has happened since the interview took place - the AJAX Toolkit Framework ATF was proposed to the Eclipse Foundation]. The Eclipse Web Tools Project [one of the existing top-level Eclipse projects] already provides support for Java Script, CSS [Cascading Style Sheets], etc. Therefore AJAX framework support would nicely complement this project.
Application Platform
One of the goals of both AJAX and the Eclipse RCP is to provide applications with a rich user experience. RCP gives you a rich user experience on the desktop and AJAX gives you a richer user experience inside the browser. There is a spectrum – classical web app, AJAX, Eclipse RCP – you have to decide where you want to be and what richness you want to provide to clients in your applications.
At the programming model level I’d say that the Eclipse RCP programming model is more homogeneous than AJAX and it has a strong focus on modularity and extensibility.
Rational (and other large-scale development tools) seem to have as their goal to permit business professionals and programmers to share a single development environment. Is this really possible? Will that get better over time? How?
The real goal is not only to share a single development environment, but to enable the business analyst, the architect, developers and others to all effectively collaborate. This can be achieved in a single development environment like Eclipse by providing business analysts and architects with a suite of plug-ins that matches their skills.
Sharing a single development environment provides you with integration on the desktop, this is good. However, the goal is to go beyond that and to provide a similar experience to the entire team. You need consistent versioning and traceability across project artifacts from business professional and developers. This cannot be addressed by a monolithic repository but requires extensible repository technology that lets you add new capabilities - both data and behavior - to the repository in the same way you can extend Eclipse on the client side. The end goal is a platform for highly integrated solutions.
What would you do to significantly improve Eclipse as it evolves?
One significant improvement is currently on the way and driven by the Eclipse Foundation [the Eclipse Foundation governs the Eclipse projects]. Eclipse has grown significantly and by now consists of several top-level projects. While the richness is good, consumers of Eclipse technology are challenged with the requirement to consume and coordinate the integration of releases from different projects. To simplify planning for consumers there is the Callisto Simultaneous Release. The goal of Callisto is to deliver ten Eclipse project releases roughly at the same time during June and July of this year.
I’m personally involved in the Eclipse Platform project [the project at the lowest layer]. This project is using an agile process which helped us to achieve predictability and quality delivery on time. While I believe that each Eclipse project needs to have its own culture I also believe that it is healthy to share things that have worked in the past. The goal should be that the things that work get shared and adopted across the different projects. John Wiegand and I have started to share what we have learned in the Eclipse Platform Project at last year’s EclipseCon and we will continue on this topic at EclipseCon 06 end of March.
This is from an interview with Erich Gamma, IBM Distinguished Software Engineer and Eclipse guru on January 13, 2006.
Note that we’ve used the convention of putting Erich’s own words in regular typeface and my questions, comments, and additions in italics.
Mar 09 2006, 01:27:00 PM EST
Permalink
|
|
IBM's SW Future Depends on its Relationship with Developers
At the top of IBM's software hierarchy, sits Steve Mills, Senior Vice President and Group Executive, IBM Software Group (SWG). A few weeks ago, Steve agreed to an informal telephone interview, with the thought in mind that although interviews are not a traditional format for blogs, his point of view would be a great way to explore the relationship between IBM software strategy, its own development community, and the developers ISVs, VARs, SIs, and developers in customer organizations it supports.
Our conversation was broad and candid. Since I picked the questions and chose which portions of Steve's answers to include, youl need to blame me if you would rather have asked him about something else.
SWG's Different Constituencies
IBM has some very different customer groups, ranging from ISVs and SIs (Systems Integrators) to the development staff in customers' IT departments. Talk to us about how you think about them and how they fit into IBM software strategy.
Non-IBM developers (ISVs and SIs as well as customer development staff) are critical for implementation. They have to know our technologies to use them or we won't sell them. Of course, administrators are important too. Everything is interconnected.
But we do look at different kinds of developers differently. There are multiple classes of developers. Customers and Systems Integrators are similar. They have a project focus. They're interested in a business result. They want to do something simple and lightweight or something robust and enterprise-wide.
ISVs are narrower. They focus on their own product and want to improve it on a regular basis. They're less driven by modeling and life cycle issues. They tend to use less tooling and do more raw, basic development, often with home grown tools. More of them want to use better tools, to be able to turn development over to a new group, and sustain the value of their assets. This means [they need] better design maps, flow diagrams, and managed code libraries.
In either case (internal developers or ISVs), we always focus on selling the tools they need for the job they're going to do. With the acquisition of PureEdge we can offer a simpler development tool for internal projects [based] on Forms Based application development. But [you have to keep in mind that] many tools extend beyond their niche and are not necessarily good for everything. More sophisticated software needs more sophisticated tools to design, tune, and manage.
Is SW Different for IBM than for Competitive Systems Vendors, e.g., Sun and HP?
Software is a much bigger and more important business to IBM (in revenue) than it is to competitive systems vendors like Sun and HP. How does software fit into the overall IBM strategy? Is that different for IBM than it is for competitors?
[Our approach to SW] makes us dramatically more competitive both in sheer quantity and compatibility.
There a big differentiation because IBM has had a software culture a very long time. Back in the 60's we sold software with the hardware. In the 70's we built operating systems and data bases.
We always had a large software community inside IBM and participated in government, standards, and academic activities.
IBM is a software investor. As software became independent of hardware IBM continued to invest. This means when companies want to develop software [with IBM], IBM has a deep knowledge and talent base. We're invested heavily in independent relationship building with the programming community worldwide through projects such as AlphaWorks, DeveloperWorks, Eclipse.org, standards groups, and Open Source.
Of the systems companies, DEC was right behind IBM, [with investments in] Office Automation, rDB, and industry segments. This investment was largely dissipated when DEC was acquired by HP. This is a missed opportunity for HP who couldn't see that the culture for software is different than the culture for hardware. It needed to let software people be equals to the hardware engineers.
Sun has a hardware mentality, too. It has a hardware vendor platform view. Software value is only realized through use; the vendor must participate in how the software will be used. Hardware is a high velocity sale. Software value isn't realized until it's put to use. It has no value when it arrives. Effective software companies have people on the ground to enable customers to install and implement the software. Sun has acquired a bunch of software companies, but they have a hardware mindset, so software has a hard time. When they can drag the software with the hardware, that works okay (e.g., the operating system), but software requires direct customer interaction and patience. Sun had Forte (which was a good product) and look what happened. Now they have SeeBeyond; we'll have to see what happens there.
From Proprietary Software to Open Standards and Open Source
IBM has been steadily moving from a traditional, proprietary software company to a mainly Open Standards company with more and more emphasis on Open Source.
IBM moved from a proprietary software company through the 80's to a company based on Open Standards in the 90's. Open Source was the next step up from Open Standards. Open Standards, with specifications and testing, still didn's give you interoperability; Open Source gets you there. ](Mills thinks of Open Source as Standards on Steroids), Open Source is a continuation of our embracing of standards.
Some Open Source initiatives have become products. (Mills offered some examples.)
An Open Source Project like Linux is implemented in a commercial product like the Red Hat which includes the Linux Kernel plus Red Hat's added offerings. The Oopen Source Project Apache is offered in the Commercial Produce WebSphere, which includes both Apache, other Open Source code, and proprietary IBM IP.
[While customers like Open Source] they don't seem to want to change source code; they know they would loose program compatibility. (Like us, Mills seems to view Open Source more as a customer insurance policy than a customer implementation strategy.)
Mills shared with us some of his views about industry Open Source activities and reactions.
On what students are learning now:
Colleges and universities teach Open Source. That's what students know and use. They expect to go into business and use them. Of course, they learn Excel (and other Microsoft products) but the market has taken a significant turn, with Open Source driving expectations in every part of the market.
On Microsoft negative statements on Open Source:
Everyone views Microsoft's statements (about Linux and Intellectual Property) as being parochial and self serving.
On Why Open Source is Exciting for IBM
We're glad we saw this (Open Source) early on with Apache and Linux. We convinced other parts of IBM [to come with us]. There's a lot of energy around Open Source. {Think of it as "Follow the Money." Technology People Follow the Energy; it's an indication of change and opportunity.
At LinuxWorld
A few days after our conversation, I got to sit in the audience at LinuxWorld and hear Steve's keynote about Linux, trends in the software industry, and IBM.
He made one observation I was fascinated with, because he shows just how far-reaching his vision of the software industry and IBM's relationship to it might be. He commented on IBM's recent acquisition of the Open Source Web Applications Server GlueCode, noting that some might wonder how he justified buying a product whose software would be offered at no cost (although IBM will offer support at a fee). IBM has offered WebSphere Express at very substantial discounts, he noted, in order to make it appealing to some customers who only need a fraction of its features. It makes more sense, he remarked, to offer a free Open Source product that better fits the customer needs.
We add that not only might IBM gain new customers this way, they might, in the future, have an opportunity to sell them other products. Selling customers exactly the right IBM software is just what Steve Mills likes to think about.
Note: The Titles are mine; Text in italics is mine. The rest is quoted from a transcript of Steve Mills' interview.
Aug 24 2005, 12:17:00 PM EDT
Permalink
|
|
How Open is Open?
Coming Back from JavaOne, I continued to have my annual debate with myself on "How Open is Open?" That's brought about by the fact that there are many varieties of Open Source licenses and many opinions as to which ones are really in the Open Source tradition.
The Open Source License Continuum
Think of it as a continuum. On the left hand side is Richard Stallman, the Electronic Frontier Foundation and the notion that an Open Source license is the GPL (and only the GLP) and that Open Source, shared, and free are all part of the same concept. That is, an Open Source license implies that the software's creator means to share the software freely (at no royalty or license fee) with anyone who wants to use it and that using it implies that any code written to extend the software will be returned to the community under the same license.
Those are tough rules for commercial developers who may want to develop on top of Open Source software, but retain their IP for their own purposes, probably revenue-producing ones.
On the right-hand side are licenses that permit users to see the source code of an application (and perhaps make modifications for internal, non-commercial use) but do not allow them to use the code for commercial purposes without paying a fee. Modifications to the code may be suggested to its owner, but control of its future is entirely with the owner of the IP. I would suggest that some (but not all) of Sun's Open Source licenses, particularly the CDDL licenses, work like this. (Sun also uses other Open Source licenses, including the GPL, for code it no longer has a commercial interest in.)
To Many Licenses
At last count there were more than 50 Open Source licenses and you need a fleet of lawyers to keep track of the differences. We use a couple of reference books including Understanding Open Source and Free Software Licensing by Andrew M. St. Laurent (Oeilly, 2004) and Open Source Licensing, Software Freedom and Intellectual Property Law by Lawrence Rosen (Prentice Hall, 2004).
The most important thing to understand is that some licenses can be used with others. The CDDL license, for example, can be used with code licensed under the GPL. For this reason, it important to understand something about licensing issues before you decide what Open Source code to include in an application and which Open Source license you might want to use for your own application.
Jul 01 2005, 04:30:00 PM EDT
Permalink
|
|
When is Software Ready for Users?
Once upon a time, developers worked on software in the privacy of their offices, writing and testing it until it was finished. Only then would they ship it to users.
Today, things are very different. Aggressive users can see code even in a pre-alpha state and large numbers of users are invited to join in what amounts to a high volume test in the code's beta period.
Some software vendors have earned a reputation for letting the users be a significant part of the testing process, looking for bugs as well as for problems with useability or missing features. In fact, many users have given up buying software (or even upgrades) on their first release, waiting for a subsequent release or service pack before they feel confident enough to try a software packaging, however appealing it might be.
But some software users revel in being able to use software as soon as possible. They enjoy every bug and bug report, feeling that they are part of the software's development process, rather than just a user.
Keep the Pioneers Separate from the Users
The trouble is, keeping the pioneers, who like to catch your arrows and tell you about them, separate from the users who would just as soon only see a software product that is complete, finished, and very likely to need little or no assistance from the technical support staff. Here are some helpful hints:
(1) Ask. Users often know whether they would like to participate in the development process or whether they'd like to spend their time on their primary work tasks. Let them know what they're getting into if they try software at various stages of the pre-gold code process.
(2) Tell. Tell users just what to expect from a pre-alpha, alpha, or beta copy of your software. Tell them what will happen to their work if a fatal bug occurs. Tell them how much support you can offer them and how that support works (email? FAQ? telephone hot line?) Honesty is the best policy here.
(3) Only offer very small rewards for participating in the development process. We note that some vendors offer BIG rewards to beta testers, leading some folks who are really unprepared for the work to take it on. Better to keep the rewards smaller to reduce temptation and to do a better job of non-disclosing just how much work you expect.
Be Truthful
I really respect a developer who tells the truth. Recently, I've been angling for a copy of a particular piece of Open Source software that's not quite at alpha. It's actually available on the web and its owners have told me where it is and that, of course, I'm welcome to download it if I want to. They've also pointed out that for someone like me who is (a) not a programmer and (b) mainly wants to see how the product looks and works, but not to help debug it, it would probably be better to wait a while.
They've figured out (correctly) that I'll have a better first impression if their baby product doesn't crash the first time I try to use it. If only every developer was as thoughtful.
Jun 17 2005, 04:30:00 PM EDT
Permalink
|
|
It all Depends on your Point of View
I'm back in Philadelphia (well, actually Narberth, but who knows where that is) and several things in the last week have brought home to me -- sharply -- something I discussed during my Rational Conference blogs. What seems like exactly the right way to do something really depends on your way of seeing the world.
Writing Blogs
For example, when I first started writing this blog, I was surprised to learn that it didn’t' have any of the formatting tools I was used to finding in commercial blogging tools. I asked questions and someone kindly explained to me a few HTML tags I could use. Actually, I know about HTML tags that just doesn't seem like a very friendly interface to someone like me, who's not a programmer or a web developer. Also, very simple things, like being able to assign a URL link to a word or phrase in my blog doesn't exist -- I just have to put the whole address, often several lines of meaningless code, into the story, interrupting my train of thought and the readers.
There is a discussion going on now about how to improve the blogging software for DeveloperWorks BUTit's not about my issues, but rather about which tools scales best (that's a fair issue for such a potentially large community), which one is politically correct (I think that's what they're talking about), and which one has the most extensibility. No one seems to care much about Ease of Use, probably because it's not an issue for them -- but it is for many of the folks they might like to see blogging or commenting on blogs who are smart and interesting but definitely not technologists.
User Interfaces Revisited
I know I've probably said too much already about user interfaces, but last week in Redmond I visited with the Longhorn folks for an overview. They were kind enough to show me (among other things) the interface for the file system. It's cool -- way cool. It's a GUI. It even has some intuitive ideas built in (like a long document has a fatter icon (thicker shadow) than a shorter document). But its whole notion of how users do work and share information -- and, therefore, documents -- seems to be uninformed by the information worker environments I know.
Maybe that just means it still has to go through more usability testing. At least at Microsoft I have an expectation it will get some. But why isn't the design informed -- up front -- by how real workers in real offices do their jobs?
This is part, of course, of a more generic problem which says developers' ideas of what makes a great user interface tends to be divorced from the users and their work. I always want to bundle them all up and send them off to a Jared Spool, www.uie.com or Jakob Nielsen, www.useit.com/ , seminar on UI design.
Gadget-o-Mania
Then I read a favorite newsletter (ezine?) of mine, by David Strohm, WebInformant, http://strom.com/awards/413.html, and howled over his all-too-apt prose about the over-gadgetification of cell phones (insert your favorite electronic object instead, if you prefer). Strohm tells the tale of how cell phones keep adding features (which he keeps passing up) and he still can’t figure out how to make an international phone call – and neither can his techno-geek friends.
I fondle my plain brown wrapper cell phone (which I am Oh-so-tempted to turn in for a Treo 650) as I read this.
The designers, technologists all, have forgotten that if we poor users can’t figure out how to use the basic functions of the phone, it isn’t useful. I didn’t know, for instance (fortunately my husband quickly told me) that you could create speed dial numbers on a cell phone. That, of course, is because I didn’t read the 60+page instruction manual, thoughtfully printed on translucent paper that accompanied my phone. Users never read instruction manuals. If you can’t use the (Pick one: device, application, toy . . .) without reading a manual, it probably isn’t going to be wildly successful.
Think of this as a cautionary tale.
And since I regaled you with tales of restaurants in Las Vegas, let me assure you that I returned home and had several weekends of good old fashioned family food, complete with a birthday party for five year old twins (traditional hot dog and hamburger cookout, amplified with lompia, since their sister’s nanny is from the Philippines), an afternoon Pot Luck Lunch on the porches and lawns of a house parts of which are over 250 years old (I made my chili corn cheese strata), and a lazy afternoon at my daughter’s house, (complete with grilled steaks and a lemon crumb pie). Next week we’re going to New York City and then to San Francisco for SuperNova and Java One so I’ll have lots of develop worthy chat and restaurant trivia to share.
Jun 10 2005, 03:09:00 PM EDT
Permalink
|
|
Finding a Common Language
I'm in Redmond, getting briefings and disclosures on current and soon to be announced products and, of course, that means lots of discussions with developers.
Once again I'm reminded of the fact that developers live in a different world that users. That makes it tough (or at least weird) for people like me who need to keep crossing back and forth across the great divide.
Developers ideas about a great user interface seem to be:
(1) It has to be a GUI -- users demand that (can't imagine why)
(2) It should have lots of pictures (icons) to make it look cool. The fact that icons without labels are often much less useful than ordered lists seems to escape most developers.
And I've discovered a new problem that I hadn't thought much about before. If the developer is trying to design an interface that will be useful to both a consumer audience and a business audience, he may be making a lot of compromises.
Now, if only I could figure out how to explain this to developers in a language they would understand. It seems too bad to just let interfaces that are unlikely to work get to the marketpolace and be sharply criticized (or largely unused). Remember social interfaces?
Jun 03 2005, 10:22:00 AM EDT
Permalink
|
|
Leaving Las Vegas
Today's the day to check out and go home. No more Elvis Imitators in the elevator (where was he going?), no more flashing lights in the casino.
But we get to take home a ton of new tools, access to more tools (You are going to check out alphaWorks, aren't you? It's at www.alphaworks.ibm.com), and -- most important -- lots of new ideas.
Here are some of the new ideas I'm taking home:
(1) The tools for communicating between the business side of the enterprise and the development side are getting better. We have to learn how to take advantage of this.
(2) At any moment in time we have tools that reflect the problems we're trying to solve and the technology that's currently available to solve them. It's important not to think of this as a permanent situation. Both the problems and the technololgy are changing all the time so, of course, the tools are going to evolve, too. We have to keep up with all this and not get frozen in some prior solution state.
(3) Because we have so many more users -- with such a wide range of tasks and skills -- we need to look for new interfaces which are much more stretchy (flexible) in providing suitable ways to serve such a diverse audience. Fortunately (I think so, but you may not agree, since you'll be writing the code -- I only have to admire the results) it's time foro new interfaces and there are lots of fordes already in motion starting to push toward change.
(4) Internal developers (those working inside user organizationns) may come upon problems and interesting solutions before such software appears in the ISV community. We have to keep looking there for new stuff, even though it's harder, since it rarely appears in vendor press releases.
That's it, except for a final restaurant report. We went to a popular local spot last night, away from the strip. Rosemary's has one of the highest Zagat ratings in Las Vegas and it's no wonder. The eclectic New American food with a New Orleans twist (the chef owners trained with Emeril Lagasse and Susan Spicer, celebrity New Orleans restaurant owners), is fabulous. How about barbecued shrimp with Maytag blue cheese slaw? Cheese souffles with wild mushroom ragout? And that's just the appetizers. A speciality of the house is "little plates" (like Tapas), served in the bar. We're definitely coming back -- to Las Vegas and Rosemary's. You can drool over the menu at www.rosemarysrestaurant.com.
May 26 2005, 12:36:00 PM EDT
Permalink
|
|
The Illusive Business Interface to Programming
Yesterday I had the fun of talking with Danny Sabbah and Lee Nackman about the next versin of RUP I had just seen in the Technical Preview Lounge and that took us into a free-ranging discussion of all the interfaces for business users to access information and model business processes that software companies have come up with over the last 25 years or so.
Time after time someone has come to me, sure that they've finally solved the problem, with a Natural Language or Next Generation offering (remember all those 3GL and 4GL products). They were better than what had come before just as RUP is better than its prcedents. But they all suffer from the same problem.
The folks who will successfully use them (in a rich and detailed way) will be people who chose to be business analysts or to play other non-programming business roles, but they probably have the mental point of view (shared by all programmers) that allows them to understand logical-sequential thinking.
It isn't bad to give them better tools where
(1) More and more of what they want to do can be selected from libraries rather than generated over and over again, usually with slight (but not meaningful) variations; and
(2) Their output can be used by the coders to generate the "real" code that will ultimately provide the outcomes the business needs
We just need to know where we are:
-- We don't have tools that someone who doesn't have the right kind of "thinking" skills could use -- yet -- and I'm still hopeful that we're going to get there, even though I only know what I want, not how to make it happen.
-- We still can't push a button once we've defined what we want the software to do and generate code. We've been looking for that dragon slayer for years, but the treasure hunt is still on. Again, I think this is not a matter of "if" but "when."
So if you can tell me how I can let a business professional "tell" the computer (I'd settle for a keyboard interface and so would most professionals) what he needs to do and software would be automatically generated that did just that, we could let the celebratory fireworks off.
In the meantime, we'll have to be happy for each improvement in existing tools, hoping that we'll figure out the breakthrough that will let ordinary mortals communicate their needs and magical software tools convert it into at least the beginnings of code.
P.S. To continue my restaurant report, last night we ate at Aureole in the Mandalay (the one with the wine cellar in a glass tower and cat-suited wine stewards to retrieve your choice). We had the tasting dinner (seven courses, ten if you count the lagniappe (little gifts) they offered along the way). It was divine. Especially notable was the Chilean Sea Bass with Porcini Mushroom in carrot ginger broth, the pheasant with foie gras, and the goat cheese and quince tart with herb salad. And then there was the chocolate hazelnut tart with tangerine sorbet and tangerines. We'd come back here -- in a year -- when our waistlines and our wallet recover!
May 25 2005, 04:14:00 PM EDT
Permalink
|
|
When Research and Development Partner
I got a triple shot of Grady Booch today -- a one-on-one meeting, his keynote, and a press and analyst Q&A which also included Software Research Manager Mark Wegman and Gina Poole, VP of Developer Relations. Like a triple shot of expresso, it perked me up and filled me with energy.
Grady spoke about the fundamentals of the development process, but a good bit of his talk focused on how Rational partners with IBM Research (managing that partnership is one of his duties). He was pleased to talk about some of the cool tools for developers that are coming out of this relationship.
Many of them have to do with improving the way developers (who often work in geographically dispersed teams these days)can collaborate and communicate about the software projects they're jointly creating. He showed a collaborative interface where develoeprs could see What they were doing, What had happened recently, Who was available to talk to, and What their colleagues were doing. While the focus today is in using collaborative technology for communication (like instant messaging, presence, and shared spaces) from Lotus' technology portfolio, Rational is also interested in incorporating semantic technology which might help developers locate information by its meaning.
One project, Jazz, is available on alphaworks, the IBM DevelopWorks site where IBM shares research projects with the development commmunity. Gina Poole, who is responsible for alphaworks, says there are usually about 200 free downloads available. About 40% of them will later become IBM products (or be incorporated into IBM products). Others may be licensed to ISVs or customers who can use the technology in their own development projects.
Both Grady and Mark emphasized that software is becoming more complex largely because IT is a way of providing solutions to the business world -- which is itself becoming mmore complex. Developer products are designed to reduce complexity enough to let developers be productive and create solutions that match users' needs and expectations.
Several analysts wondered if a current development paradigm, like SOA, is better than what went before and why. The answer seems to be that while each approach, is, in its time, the best way smart people can envision dealing with the problems of that time, it is inevitable that we will find better solutions at some time in the future, as the problems change and the technological offerings evolve. So, Mark and Grady pointed out, SOA is the "right" solution for now -- something else is likely to be the "right" solution in ten years.
I'm off to look at technology in the Technology Preview Lounge and on the exhibit floor. I'll tell you all about it tomorrow.
The Las Vegas Restaurant Scene
BTW, if you're still looking for reports on the Las Vegas restaurant scene, we faired much better yesterday. Raffles (the very elegant Mandalay coffee shop), delivered wonderful breakfasts and snacks. Lupo di Spago (Wolfgang Puck's Ittalian trattoria in the Mandalay was terrific. I had a Risotto with summer truffles to die for -- and if you sit outside the people watching is great. Tonight we're trying Aureole. Very fancy, we hear.
May 24 2005, 02:43:00 PM EDT
Permalink
|
|
Vision without Execution is Hallucination*
I usually expect developer conferences to be long on loud, rock music and arcane technical demos and short on strategic information and humor. That made the opening session and its following press conference at Rational 2005 this morning a great surprise.
The rock music and technical demos were there (and some flashing lights and weird intro sound effects, too), but that was more than made up for by straight talk about where Rational was going, how that fit into the IBM strategy -- and perhaps more important how it fit into developers' and customers' strategies -- all told with genuine good humor.
New General Manager Danny Sabbah got dual mileage out of the quote I've used as the title for this post. In his keynote session he talked about it in referring to the need to be able to build the vision -- and needing good tools to be able to build successfully.
Later, in a Press Q&A, he turned it cleverly, using it as a humorous answer to how he thought the Microsoft Whidbey project might compete with Rational. More seriously, he remarked that it is IBM and Rational's goal to provide tools that assume a very heterogenous platform. After all, one can scarcely choose the partners in one's value chain by which software platforms and applications they selected in the past. IBM does not believe that we will ever converge around a single platform, so the need for multiplatform support will continue and expand. Another conference blogger, Alan Brown, has written on the subject of Microsoft's interest in "open" and the reaction to this. You can find the post at http://www-128.ibm.com/developerworks/blogs/dw_blog_comments.jspa?blog=353&entry=73986
Of course, "Vision without Execution is Hallucination" could be a good slogan for overly ambitious projects (we never see those, of course). When developers fail to communicate to their business clients just what they can do -- or business clients fail to communicate just what they want -- the outcome is unlikely to match the vision.
The dream, of course, is that a business analyst (who presumably understands what the business needs) could go directly from defining the requirements to creating the code. Danny Sabbah pointed out, to the Press Conference, that this is still very much a dream. But we are getting better tools for communicating between business analysts and developers. So development jobs are safe for now -- and we may even create software that actually does what the customers have in mind!
Developers: I'm still looking for input on my user interface questions (see previous post). Catch me at the Rational Conference (look for the lady zipping around on the scooter) or post comments to this blog.
P.S. I keep hearing there is all this great food in Las Vegas, but so far I've been disappointed. I tried two restaurants I've been to at previous conferences that I wanted to take my husband to (he's joined me on this trip, his first to LV in a long time). We tried Chinoise (a Wolfgang Puck restaurant in the Caesar's Forum) and the Border Grill (Mexican) in the Mandalay. Chinoise has gone from being amazing fusion cuisine to being very ordinary overpriced Chinese. We do better down the street at home. The food at the Border Grill is great, but the service was very slow. Take some friends and be prepared to have a few extra drinks while waiting!
* I got the quote wrong the first time (see comments), so we've corrected it.
May 23 2005, 02:46:00 PM EDT
Permalink
|
|
Lobbying for the Users
Recently, I've been doing research and writing around the subject of user interfaces, both interfaces for applications and also interfaces for information navigation and presentation.
I've discovered something interesting. Or maybe rediscovered it is more accurate.
Developers and power users don't need much of an interface because they know their applications (and the underlying computing environment) really well. If they need to learn a new application they're often happy, even enthusiastic, to take on the task.
Ordinary users (that's most of the world) need much more help. They need interfaces that will guide them into and through the application. They need interfaces that are patient and forgiving. Especially, they need interfaces that remember that users may not know much about how computers work, but they are experts at their own jobs and deserve to be treated with respect.
That means they need interfaces where they can easily find what they want to do and do it. If something goes wrong, the computer should either recover on its own or guide the user through the recovery process with messages in user-friendly English (or whater the language of the system might be).
I'm on my way to the Rational Conference in Las Vegas which starts Sunday (May 22) and I'm planning to conduct an informal survey, asking developers I meet how they think about user interfaces.
This is particularly important because we're getting ready to start moving from the very familiar world of documents and folders to new interfaces, particularly new interfaces for the navigation of large collections of data. It's important that we pick interface designs that will make this experience easy and appealing to users -- and lessen the burden on support desks everywhere.
If you're going to the Rational Conference, find me and tell me what you think. Or send a comment to this blog.
May 20 2005, 01:53:00 PM EDT
Permalink
|
|
Developing a Point of View
A read an interesting blog today -- it talked about a liberal history professor being the guest blogger for a few weeks on a conservative blogger's site. Needless to say there were lots of negative comments -- becuse the blog's readers expected one point of view and got another. After a few days, the blog's owner had to be a guest on his own blog, reassuring his readers that he was just away on a business vacation and would be back shortly.
Whether you think of a point of view as the blog's "voice," its personality, or its bias, it's one of the reasons your site attracts readers. They like it. They can engage with it and believe it (or, in some cases, they hate it but love to disagree with it).
As you start your blog, you should not only pick a central topic -- How I approach large coding projects, Why I like to work in J2EE, or whatever -- you also need to develop a point of view. You might be:
-- A friendly expert, sharing your knowledge.
-- A kindly college professor, lecturing on some topic, but interspeersing your lecture with antecdotes and funny stories.
-- A mid-career professiona, trying to decide between going up the experts' track versus moving over to management and wht that means for a technical expert.
-- The junior guy on the team, looking for advice on how to get ahead.
Myself, I try to be a friendly expert with lots of eccentric opinions and a few funny stories. And I love to share whatever I find in my travels on the web. (I also love to cook, so I might share a food experience, if I get carried away.)
Once you've established your point of view, try to stick to it. Your audience will build up expectations and be disappointed if you change it in mid-blog. It would be as if you walked out of the room, leaving the class comedian to continue your dialogue. It's the dissonance that upsets.
So pick your on-line blogging persona carefully. Of course, if you have multiple blogs, you can be different people on each of them -- but you'll have to remember who writes for which!
May 16 2005, 02:08:00 PM EDT
Permalink
|
|
Writing a Successful Blog
I get to read a lot of blogs. Some of them are wonderful. You are drawn in and want to know more and more about the subject and the person who's writing about it. Some of them are bloodless. The information in them may be correct, even useful, but you just don't care.
Most of them are a waste of time -- there are, after all, more than 4 million blogs. Many of them are personal diaries of adolescent girls, worried about what to wear tomorrow; they're not written for us. In fact, they may not be written for anyone but their author.
Technology blogs come in many flavors, too. Some of them are so techy that only a coder could love them. Others are a beguiling hybrid of technical information, opinions about technical information, and personal asides. They're the ones I (and I think you) would love to read. The are also the ones I am hoping some of you will choose to write.
It isn't hard. This is not about writing fiction. None of us are in a competition to be the next Great American Author. It's about including in the postings about the technical subjects we care about something about our personal lives -- hobbies, home life, travels, joys and travails -- so that the reader can get a sense of us.
If you'd like to understand what I mean, read Doug Tidwell's Blog,
http://www-128.ibm.com/developerworks/blogs/dw_blog.jspa?blog=319
and you'll get the idea. I only wish he had time to share his thoughts with us more often!
Now get busy, pick a topic you care about, sign up for a blog, and start blogging!
Jan 19 2005, 04:01:00 PM EST
Permalink
|
|
Why Should Developers Blog?
All around us, everywhere on the web, developers are using blogs to communicate. Their messages are as varied as the images you find on the web, but here are some of the good things you might fund:
-- Jakob Neilsen (http://www.useit.com/alertbox/) and Jared Spool (www.uie.com/) are experts on user interfaces, Both of them blog about the importance of understanding what a good user interface might be (different for different kinds of users and different types of applications) and how to develop one.
-- Joel Spolsky, aka Joel the Programmer, likes to write about how to write good code and how to encourage developers to do good work -- he manages a group of developers himself. He's written a few books on the subject, too. You'll find him at www.joelonsoftware.com.
-- Dave Winer (www.scripting.com/) has run a few software companies, written some good software (including some of the original blogging software) and is now active in podcasting, radio-like audio blogs. His passionate rages against those who don't give programmers credit for their work are well known. So are his thoughtful pieces, lining up support for new ideas.
I've carefully avoided listing some of the dozens of programmers at Microsoft and Sun who are now writing blogs, on the theory that they're easier to find, although we'll undaboutedly talk about them sooner or later.
All of these developers have something important in common. They're very passionate about something and they want to communicate that passion to others who might pass along their passion and their art.
That's what I'm hoping you will want to do.
(1) Find your passion
(2) Start a blog and tell others about it
(3) Create a community of interest that will pass that passion on.
And, by the way, in doing that, let people know that there are talented, pattionate developers at IBM whom they need to meet and get to know.
Want to get started? Read the IBM blogs at http://www-106.ibm.com/developerworks/blogs/ and drop me a line.
Amy Wohl
amy@wohl.com
Jan 17 2005, 03:36:00 PM EST
Permalink
|
|
|
| S | M | T | W | T | F | S | | | | 1 | 2 | 3 | 4 | 5 | | 6 | 7 | 8 | 9 | 10 | 11 | 12 | | 13 | 14 | 15 | 16 | 17 | 18 | 19 | | 20 | 21 | 22 | 23 | 24 | 25 | 26 | | 27 | 28 | 29 | 30 | 31 | | | | | | | | | | | | Today |
|
Blogging as a Vehicle for Developer to Developer Exchanges
