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!


Copyright Network Professional Association® 1994-2017. All Rights Reserved.
NPA Privacy Statement