|
7/26/2002
8:52:53 AM
Software Development Expert:
Dan Haywood
Interview by S. Ibaraki, I.S.P.
This week, Stephen Ibaraki, I.S.P., has an exclusive interview with Dan
Haywood, an internationally renowned expert in software development with more
than 12 years experience in the industry. Dan occupies his time with consulting,
training, and technical writing, specializing in OO design, Java and J2EE,
Sybase technical consulting, and data modeling. His most recent book,
co-authored with Andy Carmichael, “Better Software Faster,” is most
definitely a ‘must’ read for all software architects, project managers and
developers and the only book available that discusses their “single-source
model” approach. Dan is also a co-author of SAMS “Teach Yourself J2EE in 21
days.”
*****
Discussion:
Q: First of all, thank you for agreeing to this interview. What does your
family think about your career as a noted developer?
A: They are very supportive. My wife, Sue, acts as client manager for our
small consulting company, and makes sure I keep busy. Meanwhile, our
daughter, Phoebe (just one year old) helps us keep things in perspective. I
have to thank my family for a lot.
Q: Can you describe what led you into the computing field, your time at
Andersen Consulting working as a developer on large scale projects, and your
work at Sybase Professional Services as an architect, performance specialist
and project manager? Looking back, what would you have done differently.
A: Actually, my involvement in computing started much earlier than Andersens.
Back in the early 80s, Sinclair made some computers called the ZX80, 81 and
Spectrum. I think in the US they were resold by Timex, though it’s a long
time ago! Anyway, I wrote some games for the ZX81 for a magazine (I remember
receiving a telegram and earning £42 for them, £7 for each of 6 games). Following
on from that, I wrote a book called "Creating Arcade Games on your ZX
Spectrum", which sold a few copies. In fact, I'm hoping that
"Better Software" sells as many!
But my proper career in computing started at Andersen Consulting (now called
Accenture as you are probably aware), and I joined them because I knew I
would learn a lot, get good training, and have a good company on my resume. I
was fortunate enough to be working with big distributed systems with big
development teams on significant projects. I consider AC my apprenticeship.
Sybase Professional Services was a very different consultancy. Sybase has a
fantastic product set, based on a very sound architecture. It was great to
get to know the RDBMS product so well, and I still do technical consulting
and performance tuning on the RDBMS to this day. (There comes a point when
it's in your veins, I guess!). But working in Sybase Professional Services
also taught me the client-facing, consultancy bit, something that being
buried within big teams at Andersens you don't learn (or at least, not in the
first 5 years).
What would I have done differently? Well, when I joined Andersens, I joined
their Manchester office, while my wife (then girlfriend) was still doing her
last year at Oxford. Now Manchester to Oxford is a long enough distance to be
a painful drive on a Friday night. I should have joined the London office,
and had a pleasant 1 hour train journey instead. !
But, then again, maybe I would have ended up on different projects with
different technologies, and not been doing what I do now.
Q: What led you to get involved with the J2EE book and can you provide us
some developer tips?
A: My involvement in the "SAMS Teach Yourself J2EE in 21 Days" book
was through a contract as a technical writer. I got involved because I had
done some earlier courseware development for Content Master Ltd, a technical
authoring company based in the UK. They landed this contract with SAMS, and I
was a natural choice to be one of the authors. But you can only write a book
like that (1100 pages) in a team. I contributed chapters 5 through 8,
covering EJBs, transactions and persistence.
Some developer tips? Well, let me by way of setting context just mention the
other book I've co-authored, namely "Better Software Faster". This
takes Togethersoft's Together Control Center as its inspiration, and I'll
talk about it shortly. As for developer tips for J2EE – well, why not use
Together to develop your J2EE applications? It has some great support both
for building your EJBs, and deploying them. If you know the EJB architecture,
you'll know that an EJB consists of an implementation class, and several
interfaces. There are some fiddly rules that must be followed in the writing
of the various methods of these classes and interfaces. Together allows all
of these to be manipulated as a single software artifact. Togethersoft calls
this "EJBs as first-class citizens".
Q: Your most recent book, “Better Software Faster,” is so practical and it’s
clearly evident that both you and Andy have considerable “real-world”
experience to share. There is so much useful advice on how to engage and work
on object-oriented, enterprise-based development projects. You use
TogetherSoft’s killer development app and your sample distributed Java
application is excellent—supporting both local and Internet-based clients.
There’s an interesting foreword by Edward Yourdon—he has a copy on his
bookshelf.
Will you talk about this book in general, what led you to write this book
with Andy, and what were your main objectives with the book?
A: Yes, Ed Yourdon's foreword is worth a read, and moreover you can find out
what he gets up to these days! If you want to see what I mean, go read it on
the book's website (www.bettersoftwarefaster.com). We were very pleased that
he agreed to do an intro to our book, and that he endorsed the book so
enthusiastically. We've had some other very nice quotes from people whose
opinion we respect, so that's encouraging.
The book came about originally because I wanted to write something about how
I thought Together should be used. As you may know, Together's unique selling
point is that it can render UML class diagrams from source code. That source
code can then be manipulated either by editing the source code's text (and
the diagram is updated) or by modifying the diagram (and the text is
updated). But there are still questions to answer about managing analysis
views vs. implementation views, as well as how the other UML diagrams – which
Together supports but are not kept in sync automatically – should be managed.
Another key point for me is that Together offers considerable scope for
customization. Internally it builds an object representation of the source
code, and that object model is available through a Java API (called the
OpenAPI). Moreover, non-code artifacts (such as the other UML diagrams) can
also be accessed through the OpenAPI. Together doesn't enforce or mandate any
particular development process, so the OpenAPI offers considerable scope for
adapting the tool to support any development process you wish.
Meanwhile, Andy had wanted to write something about development processes,
and how they work with the tool. My initial writings didn't amount to much
more than "tips and tricks" for using Together, so what Andy
initially did was to convert some assorted ideas into a book with a theme, a
story, and a point. Around that basis, we were both able to contribute our
thoughts on how software should be developed, using insights from our
respective backgrounds.
What we've ended up with is a book that doesn't describe a particular
software development process, but describes instead the sorts of things that
should be considered when adapting any process for your own software
development. And what we also say is, by the way, here is the tool that is
going to work the best with these ideas.
Q: It’s often the case that the analyst’s detailed UML diagrams are
overlooked or shelved by developers in the attempt to make deadlines. There
was poor synchronization between the UML model and code. Can you share you
views on TogetherSoft’s software and how it addresses these kinds of issues?
Can you comment on the iterative and incremental approach—perturbation change
model?
A: There's three things here… the analysis model, the implementation model,
and the source code. As I've said already, Together keeps the implementation
model and the source code in sync, with no effort. So the question you need
to ask is … what's the analysis model for? Of course, in the early stages of
developing your software, it's your primarily tool for understanding the
system. But as that system goes into implementation, do you intend to have
the overhead of maintaining that analysis model?
I have a somewhat cynical view on all of this, which dates to my Andersen
days. I remember writing specification and indeed detailed design documents
which were never updated once the final software was shipped. So, given that
these were expensive deliverables to create (think: fees for Andersen
consultants), you have to ask, what was the point of producing them?
The perturbation change model describes instead an approach where the
starting point is a working system already in production. Of course, that
system may have a very small set of features, but nevertheless it is in
production, tested, and stable. When a change is required, the system is
perturbed and is no longer in balance. The aim then is to modify the
implementation such that the change is reconciled and the system then becomes
stable.
To make this concrete: the change that perturbs the system would probably be
a new feature request. Tests would be written to see if the system has that
feature, and would fail (no code has yet been implemented): the system has
been perturbed. The code is then implemented, and the tests rerun. When all
tests pass, then the system is again stable.
To be honest, this isn’t anything particularly new, and you may well
recognize these same ideas in the various agile development processes that
are now fashionable (Extreme Programming and so on). However, what we do pick
up on in "Better Software Faster" is the fact that the starting
point to the development process is not a great long analysis phase, but
instead an implemented system. We have tried to reflect this philosophy in
the book's structure too. After the obligatory opening chapter laying out
some of the key ideas of the book, the next chapter dives in and looks
immediately at our working case study.
Going back to your point on analysis, we are not dismissing analysis models,
but we are trying to be honest about what they are useful for. For example,
they are great to help new developers get up to speed on a system. So, the
question instead becomes – how can we filter out irrelevant detail from an
implementation model, to show the core domain concepts useful to understand
the system. Of course, this is a question that we try to answer in the book,
using Together as our chosen tool.
Q: What are some useful tips that you can share from your book?
A: To answer this, I think I'll focus on the some of the customizations that
we demonstrate.
Together's OpenAPI allows you to write your own patterns which allow code to
be quickly developed or modified. However, there is some effort involved. A
simpler approach is to develop templates (which are also available from the
"Choose Pattern" dialog). These are simple ASCII files that use
macro strings. Together then replaces these when the template is applied.
In the book, we show some simple templates for creating associations using
the Collections API. These are based on some templates shipped with Together,
but provide additional semantics. For example, if you apply our "List
using ArrayList" template, then an {ordered} constraint is also
indicated.
As you probably know, the Collections API is not type-safe: you can store any
object in any collection. On the JavaWorld website, there was recently a tip
that showed how to create typesafe collections, along with supporting library
code. Well, it took me about half-an-hour to adapt the Together templates to make
use of the typesafe collection library. Now when I create an association, I
know that the code that Together creates for me will use that library
automatically.
Another tip. Check out Together's audits and metrics. Together parses your
source code to build up its internal object model, so it’s a relative simple
matter to analyse that code and see if it follows best practice. For example,
one audit checks to see if variables are declared within a loop, and suggests
that the declaration be moved outside of the loop to improve performance.
Meanwhile, metrics provide detailed management information. A classic example
is lines of code, but there's also more advanced metrics such as the depth of
the inheritance hierarchy.
Audits and metrics are also key for maintaining quality of your code. It
isn't necessary to enforce every audit or capture every metric. Indeed, some
audits contradict others. However, if you decide what audits are important,
or what metrics you want to use to measure progress, then they can be a key
project aid. For certain audits, Together can even fix audit violations! And
if there's an audit that doesn't exist (perhaps you have a particularly
peculiar coding standard), then you can always write your own. We show how to
do this in the book.
Q: What about the new User Interface Builder, starting in version 6?
A: We had fun trying to talk about the UI builder, because it was only
available for us to try out relatively late in our publishing schedule.
Suffice to say it's been released as an "Early Access" feature,
which is a code word for saying, "you'll be able to use it soon".
Nevertheless, it's an area where Togethersoft needs to compete, and we look
forward to seeing this significant feature develop in future releases.
Q: How would you contrast enterprise development in Java versus .NET and is
there a winner? What do you see for the future of both development
environments?
A: Java has established itself as the de-facto enterprise language, certainly
for server-side development. How to annoy a Java programmer: tell them they
code in the "new COBOL"!
Microsoft of course has a proven record on the client-side, and this surely
is where .NET will dominate. An issue that Microsoft is always going to face
is that their products only run on the Windows platform, and for some
organizations that simply isn't good enough for server-side software.
The .NET architecture of course has borrowed many of the best ideas from the
Java platform, and in some ways has taken them to the next level. After all,
there is no real reason why Java byte code should only be created from Java
source files. In .NET, the equivalent, called IL, can be created from any of
the various .NET source code languages (VB.NET, C#, FoxPro etc).
It doesn't really matter for Together whether a company chooses Java or .NET.
While Together is itself written in Java, it can quite happily render UML
diagrams for any of the .NET languages in addition to rendering Java source.
Q: How do you see the Java development environment evolving over the next
five years?
A: The Java language and APIs will continue to grow. There are a couple of
notable developments going through the Java Community Process (JCP) at the
moment, which should see fruition soon. One of these is support for generics,
similar to parameterized classes in C++. And when Java supports generics,
then so will Together.
Another JCP is formal support for meta-data. Together uses Javadoc tags in
comments to hold meta-data (e.g. the cardinality of an association between
two classes), and while that has the virtue of actually being in the source
code alongside the feature that it describes, there's always the risk that a
developer who doesn't know about Together will look at these tags and delete
them "because they are only a comment". So, an industry standard
for holding meta-data would be good.
Aspect oriented software development is bound to hit the mainstream in the
next few years, and if it does, then there's considerable scope for tools
such as Together to provide support in this area. AO could be the next big
thing. (Or then again, perhaps not!).
One of the notable implementations today is AspectJ, which requires a
preprocessor step (for historical reasons, this is called
"weaving"). It would be nice if Together's OpenAPI offered up a way
to define one's own language grammars so that technologies such as AspectJ
could be easily supported. Perhaps this will happen.
Q: Can you describe some of the projects that you have worked on and what
tips you can pass on?
A: I'll just focus on one, which was a project that I managed while at
Sybase. Initially, the contract for this project was to deliver the system
under a fixed-price basis. That phase of the project delivered two releases
in its first year; though not without a certain amount of hard work and long
hours all round. When I took over the project manager role after that first
year, the client had gained enough confidence in us to go forward using a
time-and-materials basis. On the other hand, they wanted much more frequent
releases.
I started off by planning a 3-monthly release schedule, but while I managed
to hold out for 3 months before my first release, the pressure was mounting
for more frequent releases. However, during that first 3 month period I had
persuaded the client to invest in a decent source code management system,
which meant that we could easily develop new features while supporting the
existing production system.
I also came up with an approach for capturing what I called work packages. I
defined three types of these. First, there were specification work packages,
which were effectively a paper/research exercise to define a formal
requirement. Next, there were implementation work packages, to actually do
the work. And last, there were also test work packages, which were
effectively an integration test task. Each week the client, my senior
developer and myself met and reviewed the work package status. This gave the
client visibility as to what was on schedule, what was done, what had
slipped. Because we had a decent CM system, if a package had slipped we could
still ship other completed workpackages. The point was, the client – who knew
the relative business benefit of each of these workpackages – was able to
feel in control of the scheduling.
This approach was something that I sort of developed from first principles,
so it's nice 6 years later to see the agile development processes endorsing
those ideas.
Q: Can you share your leading career tips for those thinking of getting into
the computing field?
A: I got into computing as a graduate, and I still reckon that's a good way
to proceed – but only if you are just about to graduate! Unfortunately,
computing is still an immature discipline. Comparing IT as a profession to
other established professions such as medicine, we're still at the stage of
"sure, I can fix that – now where are my leeches?"! In time, there
will be professional qualifications that mean that those with the
qualification can practice IT, and those who haven't – can't. Just like in
medicine or in accountancy. But that won't be for some time to come. In
particular, I don't think that vendor certifications mean very much.
For now, if you haven't got a track record or relevant experience, it can be
hard to land that first job. Doing a Masters conversion course may give you a
head start, but it could be a large investment for no guaranteed return. As
often as not it simply comes down to market demand. If there's a shortage of
a skill, and you have that skill, then you'll probably find someone who will employ
you. So go choose a skill that’s in demand.
An alternative is to join a big consultancy or commercial organization on
their fast-track programme. You can get some good training and do your
apprenticeship. If you find you like the big consultancy environment, then
great, otherwise there are always plenty of other companies looking for
people with this sort of company on their resume. So this is a great way to
proceed, provided that those organizations (a) are hiring, and (b) are paying
enough for what effectively will be an apprenticeship salary.
Q: What are the hottest topics that all IT professionals must know to be
successful in the short term and long term?
A: Well, the hottest topic is always changing. Distributed systems,
client/server, UNIX, CORBA, OO, Design Patterns, Java, the internet, Linux,
XML, .NET, web services, aspect-oriented programming. The list goes on. So to
be successful, I guess you need to stay interested.
Thankfully (it seems to me), the longer you stay in the industry, the more
you see the same ideas regurgitated, just with a new name. There's usually
just an extra level of abstraction that's been introduced. Perhaps that's not
unexpected. A favorite quote: "software design is the art of believing
that all problems can be solved by introducing an extra layer of
indirection". Quite!
Q: What would be your recommended top ten references for the serious software
specialist?
A: Current favourites include: UML Distilled (Fowler), Concurrent Programming
in Java (Doug Lea), Core Java (Horstmann and Cornell), Refactoring (Fowler),
Extreme Programming Explained (Beck), Design Patterns (Gamma et al),
Effective Java (Bloch), Java Performance and Scalability (Bulka), The Inmates
are Running the Asylum (Cooper). And can I complete the list with Better
Software Faster ?!
Q: If you were doing this interview, what four questions would you ask of
someone in your position and what would be your answers?
A: How about these:
Q1: Can Together make a difference to my organization?
A1: Absolutely! If your organization develops its own software using Java,
C++ or the .NET languages, then Together can allow you to develop software
that – quite simply – will be better, and develop that software faster than
otherwise. For the developer and designer, the ability to maintain and
develop source code, implementation design models and analysis views from a
single set of artifacts is too powerful to ignore. For the out-and-out coder,
Together now has an IDE feature set that is among the most powerful in the industry,
and patterns and templates and the powerful refactoring support make it
possible to get a lot of coding done very quickly. For the support guy,
Together's support for deploying to the J2EE platform and for web services
configuration is invaluable. For the architect, the ability to define audits
and other modules to ensure company standards are being supported is
unrivalled. And for the project manager, metrics, automated document
generation and other tools mean that it's easy to keep control of the
development effort.
One oft-heard criticism of Together is its cost. But no matter what deal you
strike with Togethersoft, the product is going to cost at most 10% of a
developer's salary. The question to ask therefore is, will this software make
that developer at least 10% more productive. If it can (and it will, easily),
then the software will have paid for itself inside a year.
Q2: Are agile processes the way to develop software?
A2: For the sorts of systems that I've built, I think so. But I've never
tried to build a fighter plane, so I don't know whether it is the right
approach in every development domain.
The problem with building software is that getting the requirements and
specification correct is so very hard. It's almost impossible for a business
user to sit down with a blank piece of paper and dream up requirements that,
when implemented, will actually solve the business need. It fits the human
mind so much better to show a partial solution, and then develop and refine
it. When we learn, we go from the concrete to the abstract. Developing a
system is really a learning process, for both the developer and the business.
So any process that lets us start with something concrete and then enhance
from there has to be the right solution.
Q3: Among your other roles, you're a Sybase performance specialist. Software
keeps on adding layers of abstraction and indirection. Should we care about
performance when building systems, then? Isn't it going to have a negative
impact?
A3: Yes, performance is important to consider, but consider it early (when
figuring out the architecture), and consider it late (to tune away
bottlenecks). But ignore it otherwise. When you are considering performance
early, remember it's the network that's going to be the slowest part of the
system. Disk access times in comparison are pretty irrelevant; these days
with cheap memory, most data is going to be in memory.
Q4: Is Sybase as a vendor going to be around in 5 years time?
A4: Sybase has great technology, but lousy marketing. Little known fact:
Sybase has something like 70% of the embedded database market. Now if you
were going to name one growth area for the future, then it wouldn't be
enterprise RDBMS – that market is saturated – but you might well mention
embedded and mobile systems. A 70% market share is going to be hard for other
vendors to compete with.
So, yes, Sybase will be around in 5 years time. But they may not then be
known for their RDBMS. After all, BMW don't make aircraft engines anymore
(did you know that BMW's logo was of a propeller?), but that's how they
started. So Sybase will be around. But they probably still won't have learnt
how to blow their own trumpet.
Q: It’s a blank slate, what added comments would you like to give to
enterprise corporations and organizations?
A: To be honest, I've probably gone on long enough. If I say too much in this
interview, then no-one will need to buy the book!
But I would just like to say, I'm available for consultancy and education at
very reasonable rates!
Q: Thank you for sharing your valuable insights with us today and we look
forward to reading your books, and articles.
A: You're welcome. I guess I'd better get onto writing some more of them,
then!
|
|
