Careers: Interviews
Software Development Expert: Dan Haywood
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! |
|
|