The Art and Craft of Great Software Architecture and Development

How to Motivate Developers - A three step framework

2008-12-09T19:49:00.015-05:00

No . . . . not THOSE three steps!

Anyway, now that we're approaching the end of the calendar year, invariably many folks are filling out self-evaluations and managers are presiding over year-end reviews, and choosing raises and bonuses for their staff.

Managers should also be considering the year ahead and one of the most important aspects - developer productivity. A key element of productivity is motivation and this article tries to answer the question "How to motivate developers".

But first some comments on prior work . . . .

There have been quite a few blog articles written by others on this topic (see some references below). They're pretty solid but they're mostly written from the perspective of
1) Developers or
2) Managers who don't have a major technical background.

The problem with #1 is that self-reporting of what a person wants is very unreliable. Often people don't really know what they want. Or they know what they want but don't truly understand how it will make them feel or for how long (see this really great article on happiness for some more insights)

The issue with #2 is that, without knowing the perspective of the other side (developers understanding what it means to be a manager and vice-versa) the full picture is often lacking.

One thing I noticed in my research for this post is that many of the articles below try to ask "What do developer's want?". That's important but a bit misleading. For example take a more common situation - housework. I don't want to do the dishes - I'd rather be playing Call of Duty 4 - but I *have* to. For many reasons - the sanitary one is obvious - the not so obvious one . . . . my wife will kill me otherwise :-) So what's my motivation - good health and staying alive :-) What motivates me isn't what I want.

There's also another aspect to this that I feel people haven't considered. I am going to venture (without citation . . . I couldn't find one) that the majority of a person's motivation is intrinsically determined. That is - their motivation level is largely driven by who they are, their personalities and things in their lives you have no control over.

So please don't get the idea from this that I believe one can control 100% of a developer's motivation. You can influence it, but only so much. In many respects motivation should be a key aspect when interviewing new team members - because once they're hired you can only impact a relatively small aspect of their motivational make-up. Again that's based on experience - I'm not aware of any scientific studies to confirm this hypothesis.

To repeat, I feel that, to a large extent, people are already largely motivated or not. You can improve things quite a bit though. Say you could make a developer 5-10% more effective - that's like having an extra 2 weeks to a month of their development time each year.

That's a lot of extra bugs fixed or new features produced. Do that across a team of 6-8 developers and you can make a very noticeable improvement.

Anyway after thinking about it - from both a managerial and developer perspective, here's what I've come up with for my framework.

STEP 1) Compensate Well
This is one of those "necessary but not sufficient" conditions you often hear about. You can address every other motivational item but if you don't pay well and give good benefits you're shooting yourself in the foot and worst of all people are going to go elsewhere. Probably most of all you're just not going to be able to attract and retain really good (i.e. already motivated) developers.

If you think of the famous Maslow's Hierarchy of needs, this is one of those fundamental "lower" or more basic needs.

STEP 2) Remove or reduce demotivating aspects
You can pay all the money in the world to people but if you have non-existent specs, unrealistic deadlines, micro-manage etc. people aren't going to be motivated for long and they will quickly become unmotivated or leave.

As I just stated there are several things that many developers experience that drive them batty.
i) Poor requirements - there's nothing worse than building junk but consequently (for me at least) there's nothing better than great (detailed, unambiguous) requirements and the resulting happy users.

ii) Unrealistic deadlines - whether this results in 90 hour+ weeks or buggy software - this is very much a drain on developers, their ego and sense of pride. Developers want to be proud of their work and go home and see their families. Is that too much to ask?

Yes everyone has crunch times and there's invariably some extra unforeseen work but hopefully it's infrequent and as a manager hopefully you don't have to "go to the bank" too often.

iii) Too many meetings - I've found that the more formal a place is (or the less friendly it is) the more meetings you need to just get people to talk to each other. But many meetings are a bad sign - ideally developers would/should be able to talk to each other and meetings should be "organic" and not forced.

iv) Disrespectful or uncooperative colleagues. "Bad apples" can ruin a whole batch. The problem is exacerbated when management is unaware of them or worse, is aware, but refuses to do what it takes to remedy the situation.

v) Processes, Tools or Techniques that slow you down e.g. slow builds, slow unit tests, slow desktops etc. They suck productivity and reduce enthusiasm.

vi) A poor work environment e.g. a place where it's too loud, there's no privacy, you get lots of interruptions etc.. A bad environment can destroy motivation or at the very least be a distraction. And distractions are TERRIBLE for a developer's focus on the problem at hand.

Either way, my recommendation is that before focusing on MOTIVATING factors, I would focus on removal or amelioration of demotivating factors. There's also some evidence that there is some psychological difference between demotivating aspects and motivational factors.

The good thing is by focusing on these e.g. improving requirements, reducing unnecessary meetings, speeding up processes etc. you are also improving team productivity even if there's no motivational boost to be had. But that's unlikely - removing some of those impediments should buy you some good will - but frequently that fades over time. Either way, for the productivity boost alone that's makes good business sense.

STEP 3) Focus on positive motivational aspects.

Here are the things that you really are hoping will translate into more motivated (and more productive and happy) developers

i) Support Developer Learning
Developers love to learn - new languages, new tools, new frameworks. Spring, Ajax, Hibernate, Ruby - that gets their juices flowing. Now the challenge is how do you direct that to produce the product you're paid to . . . . . the key here is to align the new item with key gaps needing filling. Need an Object-Relational Mapping system - Hibernate! Need a rapid prototyping language - Ruby! etc. You also need to factor in the productivity dip as they learn.

ii) Provide Challenges & Problem Solving Opportunities
Developers in general love to solve problems - whether it's how to integrate new features into a legacy system, how best to compare two lists of strings or how to make a system more scalable developers love such problems.

In my experience however there are sub-types - different developers who prefer different kinds of challenges - ideally again you would align the challenge to the person who wants it!

iii) Provide Feedback
Developers want to learn and grow - beyond the technical learning / challenge they also need feedback in other ways to help them grow as individuals and adapt to their organization. Often I find this is where management falls down. Who could blame them / us - we often say we're open to hearing about areas needing improving but not so good in practice. I've found the Sandwich Feedback Technique works quite well though.

iv) Other Ideas
See the section below for other really good ideas from other articles

These are all the things that "developers" want, in the sense of the higher "self actualizing" levels of Maslow's hierarchy. Again, these factors should not be detached from "conditions on the ground" as it were.

For example I've known a few developer's whose idea of self-actualizing was deciding what to eat for lunch that day. They didn't want to learn ANYTHING new - no new languages, no new environments - they know what they have and don't want to change. Their motivation isn't going to take a boost from being asked to learn something - on the contrary.

STEP 4) The Secret Step - Fear as motivator
OK I said there were three steps, but here's that "magic" 4th step. The "nuclear option". Go here only when you must e.g. you or someone on your team might be fired unless some action is taken, a client could lose a lot of money etc.

As with the "doing the dishes" analogy, there comes a point when you have to do what you don't want to do. You do it because the ramifications of not doing it are worse - MUCH worse.

Often if you're seen as the "good cop", you need a "bad cop" to make this work. Sometimes you might need to be the "bad cop". Most folks know the analogy having seen it many times on the various CSI or Law & Order shows on TV.

Basically the line here is "Do this or you'll lose your bonus / won't get a raise / be fired".

As I said you can't rely on using this too often, but you need to be sure also that people know the chance is there. Developers are smart people - if you don't follow through on what you promise you lose credibility. This lesson on follow-through was something that my two year old taught me. "If you don't get down from that chair, you'll get a timeout". Guess what, unless you start handing out "timeouts" they just will continue to stand on that chair.

Again you don't want to do it too often and when you do you need to explain the reasons, it can't be seen to be arbitrary. For example - fire too many people, and people will start updating their resumes and looking elsewhere rather than live in fear. Don't fire anybody and you send the message that there are no consequences and people want to leave because they tire of supporting the slackers. It's a fine line but most of your strong developers already can identify who isn't pulling their weight and will thank you for pulling the trigger and finding someone better.

Anyway there's my thoughts on developer motivation - I look forward to your comments.

REFERENCES TO RELATED WORK

Nine things developers want more than money
1) Being Set up to Succeed
- Good requirements
- Realistic Deadlines
"Being forced to build crap is one of the worst things you can do to a craftsman"
2) Having Excellent Management
3) Learning New Things
4) Exercising Creativity and Solving the right kind of problems
5) Having a voice
"When a developer speaks, someone should listen. When several developers are saying the same thing, someone should listen and act . . .quickly"
6) Being Recognized for Hard Work
7) Building Something that Matters
8) Building Software without an Act of Congress
9) Having Few Legacy Constraints

Top 10 ways to motivate geeks
1) Geeks are curious. Let them feed their desire to learn things
2) Geeks like to be self-sustaining. Let them figure things out on their own.
3) Geeks are creative even if they don't know it. Give them a chance.
4) Geeks need tools, good ones. Give them more than they need.
5) Private, yet collaborative. Geeks need to be left alone, but not too alone.
6) Free stuff. T-shirts, food, desktop widgets, whatever.
7) Control
8) Geeks need recognition
9) Freedom
10) Compensation - Saved this for last, but geeks gotta live too

Motivating Software Developers
1) Allow me to focus
2) Allow me to feel that I am making progress
3) Allow me to make something I can take pride in
4) Allow me to do it for me, not for the money
5) Allow me to work on interesting problems
6) Allow me to be part of a team
7) Allow my ideas to be taken seriously

What motivates software developers?
1) Introduce new technologies and techniques
2) Practice pair programming to encourage communication, sharing of skills and team building
3) Encourage participation in community developer events (user groups, code camps), blogs (share links across the team), books (monthly bookshelf anyone?) and conferences.
4) Avoid generalized training - in my opinion this tends to serve the paycheck programmer more than the dedicated ones.
5) Interesting projects
6) Satisfy your customer

Motivating Software Developers

To Motivate or not to demotivate
"Only taking away the things that make people dissatisfied, will simply result in people having neutral feelings towards their jobs."

Some programming principles: People

Managing and Motivating Developers: Tips for Management Cluefulness

What makes people tick - 10 motivation factors in the workplace

"The first thing to note here is that most people are motivated by:
1. doing interesting stuff
2. feeling recognized and appreciated
3. making an impact"

What motivates programmers?

11 ways to motivate geeks

Five things your manager could be doing better

To Beta or not to Beta - That is the question

2008-12-01T19:34:00.008-05:00

"Whether 'tis nobler in the mind to suffer the slings and arrows of outrageous bugs, Or to take arms against a sea of defects, And by opposing end them." (with props to Bill S.)

In the past few years it's become more and more acceptable to release "Beta" software to the public - almost as if it was a production release.

The reasons for that I believe are manifold but boil down to
1) Gain user feedback
2) Release early to gain "mindshare" and/or get first to market.
3) Your QA process or team isn't that great (or your unwilling to spend money on them) and you'd rather have users do your testing for you.
4) You need to gain the confidence of your customers / investors in what you're building.

The number one proponent of the Beta, I must say is Google. I've been a Google Docs user for well over a year now and I love it - but it's still in Beta. The one thing I don't love is the FREQUENT UI changes in direction though - but hey it's a Beta and it hasn't lost a Document or Spreadsheet of mine yet.

But it's clear from using what Google call a "Beta" that their goals are really predominantly #1 (user feedback) and probably to a lesser extent #2 (mindshare). It's been very well tested (internally) before it hits the public. You can read more of what Google think about Betas here.

So the quality of their Betas is quite high (see also gmail) and a Beta for them is probably a production release for 90% of everyone else.

Here's the problem though - in making Beta's "popular" I think they (and others) have lowered the bar at least insofar as management can now look at it and say "Well if Google did it - why can't we?". So there's a tendency now to ship lower quality software and at the last minute people decide to slap a "Beta" label on it if it's not up to snuff so that they can declare victory. Then they hope people will use it as if it was production quality.

Personally I think software professionals should be using a public "Beta" ONLY as a last resort. If you need to gain user feedback - try not to be cheap about it. Get a bunch of potential users in a room and have them use your product - try not to prime them - just watch them. Video them. Understand what are they trying to do - how does that align with your product? Can you make your application so easy to use it doesn't need a manual? That should be the goal (although that might be ultimately unattainable any progress in making your application easy to use is good).

If the reason is #2 (to be first to market) then I think you don't understand technology trends. Neither Google or Internet Explorer (or Firefox) were first to market - look where Yahoo! and Netscape are now.

I guess I never really "got" the whole first-mover advantage thing. Think about it:

Apple vs. Windows (and back again)
Ford vs. Toyota
Betamax vs. VHS
Atari vs. Nintendo
WordPerfect / WordStar vs. Office
Friendster vs. Facebook vs. MySpace

The anecdotal lesson I got from these cases was to NOT be first mover and learn from the other guy and where he fails.

Anyway if you're in the position of #3 (you're not investing in your QA team/process) then that's a sorry state of affairs. Although we live in a world of finite resources - finite dollars and hard-to-find tech experts so I guess it can be excusable sometimes. But if you just punted to force your users to do the bulk of your testing work then shame on you.

If you're in position #4 - releasing a Beta to the public to gain confidence well it's hard to argue too much with that given the sorry state of "production" software these days (*cough* Vista *cough*) people's expectations are sadly low so its understandable people (especially investors, customers) want some reassurance.

Don't get me wrong on this though - I'm not the type of guy to wait until the product is perfect. It's more a question of what are your motivations and are you being lazy in releasing a Beta? If you want user feedback - GET USERS and GET THEIR FEEDBACK! Don't ship junk!

After doing some Googling I came across a blog article with similar sentiments
A call for revolution against Beta Culture

"I'm mostly tired about the fact that it seems that we all have given up. Tired because . . . . in reality, it's laziness and a poor job on the manufacturer part that we have accepted without questioning. Instead of calling foul play and refusing to participate, we keep buying."

"That's the key: We have surrendered in the name of progress and marketing and product cycles and consumerism."

Right on man - it just doesn't feel right. It feels lazy and short-sighted.

Here are some other thoughts by other folks

So here's my question to you, dear reader, what is your opinion on Betas? Useful software engineering technique or cop-out?

JarFinder.com - Where have you been all my life?

2008-11-13T21:03:00.003-05:00

Ever have that moment where you discover a great little tool and you wonder "Where have you been all my life?"

Well I had that moment today when I finally came across http://www.jarfinder.com/

Ever have a hard time tracking down which Jar a class belongs to?

My bane is org.apache.xml.serializer.Serializer

It turns out it's in Xalan of all places (and I can never seem to remember that).

Now with http://www.jarfinder.com/ you don't have to struggle anymore to find the jar that contains that class file.

Turns out this has been out there since at least early 2006 - wow.

Book Review: The Definitive Guide to Terracotta

2008-08-25T08:55:00.021-04:00

(Please Note: Apress, the publishers, kindy offered me a Java book to review for my blog. I accepted and out of > 100 options I chose this one due to my love of all things scalability and because Terracotta seems to address a hard problem of distributed cooperation within clusters. Anyway I guess the point is, I got this book for free, some may consider this places me in a slight position of a conflict-of-interest, some may not care. I certainly don't believe it has colored my view of this book - but you, dear reader, should be aware nonetheless. In any event I am certainly appreciative to Apress.)

Over the past few years as principal engineer / architect (and back again) I've faced a couple of hard problems which I'm sure many of you have too. Once you get to an architecture where you have more than one JVM or server, how do you quickly and easily share information across them? Yes the database is one easy solution but the performance / scalability hit in "always going to the database" becomes quickly onerous.

Then one decides to cache to reduce this load but now how to you keep caches in synch?

Then one might go down the path of deciding to use some messaging system (e.g. JMS, Tibco, WebSphereMQ etc.) to ease intercommunication but there the amount of coding, testing and debugging needed due to the complexity of this roll-your-own solution becomes quite problematic.

Another similar problem comes where you have a load balancer in front of your web / app servers for performance, DR and HA reasons and you have some stateful application (like most web sites are today). How can you share easily session information across servers to make for a seamless experience?

So for all of these problems that's where something like Terracotta comes in. It basically sits between your application and the JVM and allows you to declaratively define what information is to be shared across JVMs. It promises to do so without any code changes (nice!).

A compelling product to say the least. Anyway, in a bid to learn more about this product I decided to review this book.

TITLE: The Definitive Guide to Terracotta: Cluster the JVM for Spring, Hibernate and POJO Scalability
AUTHORS: Terracotta, Inc.
ADDALL: Link

CHAPTER 1 Theory and Foundation: Forming a Common Understanding
The first chapter starts by laying some foundation and defining terms - always a good start. "Terracotta is a transparent clustering service for Java applications" is the mantra and they go on to explain what this term means. They proceed to talk about how the underlying memory model that Terracotta gives you (across JVMs) is now transparent to the application.

They discuss at a high level how the service provides you advantages such as high availability, scalability (scale-out) and improved performance (by not requiring a DB hit to share information).

As examples, they cover the classic use-cases of Terracotta
1) Distributed Caching
2) Database Offload
3) Session Replication
4) Workload partitioning

CHAPTER 2 History of Terracotta
Chapter two discusses the forces that resulted in the creation of Terracotta - from the forces to scale out rather than scale-up (e.g., preference for loose coupling, availability of cheap commodity hardware, cheapness of linux etc.).

But with scale-out comes the problem of keeping JVMs / Servers in synch. The solutions such as
1) Scale the Database
2) In-memory replication
3) Partitioning the data

each came with their own problems.

And so Terracotta came into being. Whereas folks such as Amazon (and eBay) took the approach of "eventual correctness" (aka "eventual consistency") where each application instance could complete transactions to local disk and eventually flush to the database, Terracotta's founders chose another solution as their business folks were "not prepared to discuss the ramifications of an eventually correct architecture, where users might be told that a previously confirmed purchase order could not be completed because of miscalculations in inventory long after checkout completed".

And so they sought to effectively create a "General Purpose L2" cache. The original implementation was too intrusive where developers would often forget to serialize and replicate changes to L2-based objects to keep things in synch and this led to regressions and eventually to a significant slow down in the pace of development.

With Scalability and Availability often becoming opposing forces it was refreshing that their solution aided both. The transparency of the solution also does not necessitate the need of one programming model over another e.g. EJB vs. Spring or JPA vs. Hibernate vs. iBatis.

CHAPTER 3 Jumping Into Terracotta
Ah here we go - C O D E! They literally start off with a simple (clustered) "Hello World!" example and start to get into how to configure Terracotta. I wish they had spent some more time here, perhaps a whole chapter, helping someone set-up a REALLY good environment (say multi-machine, or at least an env for multiple programs operating simultaneously) - a lot of this is left up to the user to figure out, let alone perform. That I think dilutes the message of Terracotta and doesn't give the reader a good "WOW" factor when they see this in operation.

In any event we start to get into the "meat" here and discover how Terracotta ensures all changes to shared data have been applied before a read is performed. And just after a write, Terracotta ensures that all memory changes are made available to other Java processes that might need them.

CHAPTER 4 POJO Clustering
So having seen a quick example they correctly now need to dive in to expain how Terracotta handles Java objects and the virtual heap and secondly explain how Terracotta manages thread coordination between JVMs.

They define a "root" - a field in any class that you declare as being clustered. Terracotta traverses the graph of object references from that root to cluster those objects too. Since these objects are clustered and durable beyond the scope of a single JVM they are sometimes referred to as "superstatic" - having the same lifecycle as the virtual heap.

Typically data structures like Map, List and other Collection objects are chosen as root objects.

Terracotta is pretty smart since not EVERY object on the virtual heap needs to be instantiated in every JVM. Terracotta can load an object as needed. Just like the virtual memory subsystem of a modern OS swaps contents to and from physical memory and disk, Terracotta lets your application behave as if there was an almost unlimited physical Java heap.

Then comes information on such topics as Distributed Garbage Collection and how threads are coordinated - again the details are such that there are no real surprises or "tricks" here - the folks at Terracotta have really taken Transparency to heart. "Terracotta provides exactly the same access serialization, coordination and visibility guarantees to threads in different JVMs as the JVM itself provides to threads within the same JVM".

Then we get into more meaty topics of locks in Terracotta and how Terracotta extends the concept of locking. Again by using declarative methods they help keep much of the messy coding inherent in locking out of the developers hands and keep it where it belongs - in the Terracotta infrastructure.

From there we leap to Terracotta "transactions" wherein Terracotta batches changes made to objects into sets, helping to ensure that threads always see a consistent view of clustered objects.
From there we delve into what kinds of objects are not "Portable" (cluster-able with Terracotta) e.g. file-system related classes such as java.io.FileDescriptor (host-machine specific) and instances of java.lang.Thread (JVM-specific) are some examples.

Interestingly there is also the concept of "Physically vs. Logically managed objects" . The former are objects wherein their field data values are distributed to the Terracotta server and from there to the other cluster members. The later (Logically managed) are clustered by Terracotta by recording the method calls on those objects and their arguments and replaying them on the other members of the cluster.

Examples of logically-managed objects are Hashtable, HashMap and HashSet (spot the common theme?) - yes that's because the Hashcodes used to create the internal structure of the object are JVM-specific.

From there we get more into understanding Clustered POJOs but personally I felt much of this information was repeated either earlier or later in the book. But after that there's a more fully formed example used to elucidate much of what was discussed earlier in the chapter.

CHAPTER 5 Caching
We begin this chapter with a discussion of caching and the trade-offs and problems it incurs

Space for time
Freshness
Complexity
Durability
Duplication of data across caches

Then a quick example shows how Terracotta can be used to quickly provide a distributed cache.
From there we delve into which of the Map structures are best for such data structures within Terracotta. Interestingly ConcurrentHashMap is generally the best choice when sharing maps but sadly LinkedHashMap is not supported by Terracotta. Harumph!

Then we get into some of the gory details of caching that we all need to know

Eviction and Expiration policies
Persistence
Distributed Caching (again I felt this was repetitive)
Use of partitioned data

Interestingly they claim that it is largely by avoiding serialization (typical of transmitting updates through a cluster using more traditional methods) they gain a very significant part of the performance improvement of their product.

From there we get a quick example with Ehcache (Easy Hibernate cache) and then onto chapter 6.

CHAPTER 6 Hibernate with Terracotta
I found this to be my favorite chapter - quite a bit more details in it than other chapters, good solid examples, and the benefits of the product become abundantly clear.

We start off with a great overview of Hibernate and how Terracotta can be used to improve it - by clustering the second-level Hibernate cache and also by using it to cluster Hibernate session objects.

From there we get a good example of how Hibernate and Terracotta together can be used to save on DB hits. Hibernate's cache runs the risk of staleness if another JVM updates data in the Db and so Terracotta helps fill this gap by preventing such staleness issues.

Then we get some great stuff lacking in other books - HARD NUMBERS!
Hibernate clustered with Terracotta gave a 4x boost over Hibernate with second-level cache alone when focused on DB updates. When focused on DB reads, we get a > 250x boost. Naturally your mileage may vary but at least we're getting some good ideas of what to expect.

We now get into the details of configuring Hibernate to be aware of Terracotta and vice-versa. All straightforward and relatively simple stuff.

CHAPTER 7 Extending HTTP Sessions with Terracotta
This was another good chapter on how to share HTTP Session information across JVMs, servers using Terracotta. A very useful feature that helps avoid most of the problems associated with persisting HTTP session information to afford your cluster the ability to scale-out, be HA etc.

Yet again we see the Transparency of Terracotta as it transparently (to your web app) hooks into the servlet container. From there we get a few nice examples to see all of this works with Tomcat. Fortunately Terracotta supports the following web / app servers

WebLogic
WebSphere
Jetty
Apache Geronimo
JBoss

and the following frameworks

Struts 1.1
RIFE
Wicket

CHAPTER 8 Clustering Spring
Here we get a pretty short chapter where basically the point is you can point Terracotta at Spring beans rather than declare each class / field yet again in your Terracotta config file.

CHAPTER 9 Integration Modules
Terracotta supports the idea of external configuration for a component you might be shipping that takes advantage of Terracotta's features. This allows you to ship a Jar and the user of that jar then does not need to include Terracotta config information for this component into their own Terracotta config.

This feature is called a "Terracotta Integration Module" or TIM. It consists of config info and perhaps code that specifies how the component should be clustered, how locking is performed etc. They then go on to describe how TIMs are created, used and configured.

CHAPTER 10 Thread Coordination
This chapter seemed like it should have been more up front, also it's quite short and I thought there would be more here. They get into some of the details of thread coordination in relation to Terracotta. I got something out of this chapter - I'm just not sure exactly what it was.

CHAPTER 11 Grid Computing Using Terracotta
Naturally Terracotta lends itself to Grid computing i.e. supporting the splitting of a workload across nodes. From there we get into the "Master/Worker" pattern and an implementation in Java and then into how to refactor the original example for improved performance / scalability by reducing contention, batching work, multiple work queues, addressing fault tolerance.

CHAPTER 12 Visualizing Applications
Finally in chapter 12 we learn about visualization techniques and tools to help you comprehend what a cluster is doing and why it is going slow or fast. They show many metrics the tools capture and what they reveal and how they can be used to tune your application.

REVIEW SUMMARY
This is a rock-solid book with a solid introduction. I wouldn't agree that it's a "Definitive Guide" - but I guess that's just an Apress standard naming convention (the same way Manning has the "In Action" series).

I'd like to have seem more help up front in getting your environment set-up for the examples, some case-studies of how Terracotta has been used, more benchmarks, perhaps even benchmark code. But given the fact that it's the ONLY book I can find on Terracotta it's fortunately pretty good and gets you "in the game".

Clearly Terracotta can't have infinite scalability - Terracotta must communicate between JVMs over the network so a guide of best practices, practical limits etc. would have been useful on things such as how to optimize network architecture, data structure design / optimization etc. would have been great.

PROS: Relatively Short and to-the-point. Examples are simple and straightforward.

CONS: Not enough examples. Not enough code. Would be nice to have them help you set up an environment. Would have been nice to see some more hard numbers of performance / scalability boost over other solutions. Quite a bit of repetition - typical of books written by teams without a clear "separation of concerns".

GRADE: B+

BUY IT? If you're using starting to use Terracotta - absolutely. If you're interested in making your application faster or scaling-out in general - probably.

A sad passing

2008-07-25T17:41:00.003-04:00

Randy Pausch sadly lost his life to Pancreatic Cancer. He was 47.

Link

His life, his work and his brave struggle against indomitable odds (Pancreatic cancer has a 5% survival rate after 5 years) was an inspiration to many. He is survived by his wife and three young children - 6, 3 and 2.

Wherever he is, his spirit I'm sure continues that quest for knowledge and to share that knowledge with others.

To quote T. S. Eliot

"We shall not cease from exploration, and the end of all our exploring will be to arrive where we started and know the place for the first time. "

Automated Regression Testing: Why, What and How

2008-06-22T09:53:00.015-04:00

Having to wear the hat of three different roles (Architect / Manager / Developer) you find there are few things in software development where there isn't a significant trade-off depending on your role and it's viewpoint.

For example when I'm managing, things like refactoring take a back seat to rolling out new product - even though I'm aware of the positive impact of refactoring. When being an architect I'd rather minimize code duplication (or triplication) - a long-term gain to team productivity but at the cost of product in the short-term. When developer I'd rather be focused on developing the cool new product than bug fixing. There's few things I can wholeheartedly stand behind when having to wear all three hats.

However good automated regression testing is something that I'm pretty sure everyone can agree on. It's usually not a huge investment of time but the payoff is large and grows over time - like a savings account.

From each point of view

Developer --> Less Time bug fixing. I can go home before 7pm. Yeah!
Manager --> Better quality product, risks identified earlier. Less screaming customers! Yeah!
Architect --> Great way to support refactoring with minimal product risk.
QA --> Less manual drudge work.

Probably several of you are asking - "OK but what is a regression test?". Put simply it's testing that finds bugs in code that used to work in past versions.

WHY
As mentioned above, regression testing is first and foremost a "risk reduction" exercise - you want to find bugs in code as fast as possible with minimal effort (automated!). This becomes more important the longer your product has been in production - no-one wants a release to be "three steps forward and two steps back". You want your product to always be increasing it's value to your user base. Bugs will happen - you just want them to either be minor ones or stuff in your new code - not the old stuff that people rely on to get their job done.

In any event, people's expectations for software these days are sadly low (Thanks Microsoft!) so delivering anything reasonably reliable gets noticed.

It also acts to reduce the "drudge" work of manual testing. That work is also subject to human memory - unless you have all the test cases written somewhere - are they all up to date? You sure? For the most part the answer to that is no.

Similarly automated regression tests also act to codify and formalize one's experience so, God forbid, you lose a QA person, a product manager, developer etc. You don't lose the entirety of their knowledge.

Although some would argue this makes those roles more replaceable - in my experience it acts to free up QA, Developers, Product managers to do more valuable - and LESS replaceable work.

It also helps your team be "more proactive and less reactive" (forgive the management speak). But as we all know - the more your team spends fighting fires the harder it is to have a truly enjoyable work place. Or at least that's my opinion.

HOW
So how do you "regression test"?

0) Stop Here!
First I'm going to assume some things - first and foremost that you have a source control system. If you don't then that's the first order of business - get one! SVN, CVS or whatever (personally I prefer Perforce - actually I love it).

I'm also going to assume your team or organization cares about product quality - no problem right? Think about it though - think about your past work experiences. I've been in several situations where there was no will to do any regression testing of any real merit - I tried to fight the good fight but sooner or later you get labeled as obstructionist. True you can't spend all your time on this - but if you can't spend a few hours per week per developer you're in for trouble. I'm sure I'm not alone in this experience.

1) Unit Tests
Well JUnit test cases are an obvious place to start. So obvious I won't spend time on them - the benefits and myriad and have been discussed ad infinitum (nauseum) here and elsewhere.

The key though is to remember to also focus on unit testing from a product point of view as much as one can - not solely a code point of view. Although code coverage tools are helpful too - 100% code coverage doesn't really mean as much as one would hope (see this great article by Andy Glover).

Also remember you don't just want to test functionality (both positive and negative cases) but also, if you can, performance / scalability and security.

2) Automated GUI tools
Assuming your product has a GUI you'll probably find yourself or your QA automation team writing scripts in some tool such as Segue Silk, HP/Mercury WinRunner, Quick Test etc.

These tools are good because it's very hard to unit test a GUI. The number of paths through the GUI are myriad for anything more than the simplest UI.

However these tests are often much slower than unit tests and require significant resources - both people and machine to run.

Again don't just focus on tests for functionality but also look at testing performance/scalability and security (and I'm sure other things too)

3) Projects-specific ways
Often you'll find ways that are specific to your software or project. Some examples are below

EXAMPLES
Two examples I'm very proud to have been a part of are described here.

The first was a product where my firm transmitted data to another firm - financial information about products we had for sale. The products were then advertised on the other firm's web site.
The key problem was that the data was constantly changing (think stock prices) so the information had to be pretty current (not totally real-time but a gap in minutes was about the worst we would tolerate).

Fortunately this customer had a test system which we could attach to - upload data and verify that any changes we made would still would work. How to tell it all worked as it was supposed to? I wrote a Java program using HttpUnit that would login to their web site - find the appropriate product pages, parse the HTML and pull out the prices. Then it would compare that data against what was in my local DB (the data I was supposed to send them).

Once I had run that for an entire day without issues I was extremely confident that all was right with the world.

Also a nice upside was I could run that SAME program against our production system (it's read-only after all) to verify that production was fine.

Now the REALLY cool thing was when something happened in production e.g. network outage or some remote problem typically I could inform my user base and my management very quickly. Often they would know before our business partners were aware that THEIR system was having problems. It's really nice to be able to have that level of confidence in your product and your users and management notice too let me tell you.

Another good example was more typical to software product firms where one has many customers running the product. Typically as we're solving problems with this product we would get copies of their databases to debug issues. In turn we would take several of these customer databases and run them through nightly regression tests.

The test would compare the current release vs. the last known release (considered the "gold copy"). Not only would we diff results but also we'd compare execution times. And although the environment was not totally locked down for a true performance comparison - a 20%+ discrepancy of performance for > 1 day was typically a sign of a potential performance issue in something in our code or the data model, indexes etc.

OK enough bragging . . . let's talk about some best practices.

BEST PRACTICES

#1) Find and Test the Gaps
Testing is never done and neither will your regression testing. Naturally you will (or should) want to test the riskiest pieces first - places that have largest impact if they break and/or break frequently. Often too you should use customer feedback and bug reports to help guide your list of functionality to add to the test. Look for patterns - key areas of misunderstanding or bugs. Code coverage tools can also be helpful but don't rely on them to tell you when you're done.

Keep a prioritized list of areas to cover - start at the top and work your way down.

#2) If you're not finding bugs ask why?
One way you're regression test can stop finding a lot of bugs is if it's out of date - if you haven't been spending time adding to your test suite (you're adding more functionality say?) then you're short-changing yourself. With every release of your code - your regression test should grow or improve.

Another is if the tests being created aren't aligned with what's known for risky / bug-prone areas.

Another is when your developers are so damn good they don't have bugs anymore - but we all know that's not all that common. But often you'll find that's because they run the regression themselves when they realize how valuable it is.

#3) Have dedicated hardware
You don't need the biggest, baddest machine - often a recent late-model desktop will suffice in most cases. But you need this to do #4

#4) Run them all the time or at least nightly
Your tests should be running all the time or at worst - once per night. Once your tests are big enough there may not be enough time in the day on on existing hardware - so you may wish to keep some long running lower priority tests for the weekend or alternate test suites every other day.

#5) When you max out - throw hardware at it
Hardware is a commodity - it's cheaper to buy some high end Solaris hardware for $10k than it is to take two months of a developer who earns $100k per year plus benefits to speed things up. So when you start to max out your current regression test machines throw hardware at it first - then improve the performance (unless there's some blindingly obvious quick fix in software).

#6) Critical tests first
In the spirit of "fail fast" and risk mitigation - you first want to perform the tests that will find the most critical items or test bug-prone pieces of code.

#7) Automate Result Interpretation
Once the results from your regression test are ready it should email relevant people and provide a synopsis of the results. A daily regression isn't very useful if it takes an hour to figure out if you passed or not. Eventually no-one will read it.

#8) Add tests continuously
Don't wait for a particular "phase" of the project to add more tests - do so continuously otherwise you'll find that time suddenly disappears and then you're playing catch-up.

#9) Don't reinvent the wheel - use tools
If you're going to automate don't waste time - use the all the tools you can. There are so many great tools out there from open source to commercial (although I must say the commercial tools I find VERY expensive compared to their utility).

Selenium
Canoo WebTest
JUnitPerf
JMeter
HttpUnit
AutoHotKey -- if you don't know this already - check this out ASAP!
Apache POI especially if you produce reports in Word Doc / Excel format
Good ole unix diff, pipe and sort (this reminds me why I dislike Windows as a dev platform - Unix tools rock so thank God for CygWin)

And there's probably a half-dozen I'm not aware of that I hope you, dear reader, will tell me about.

Don't forget static code analysis tools too (See "Analyze this - put your code on the couch!") to help find bugs (e.g. multi-threading) that your regression tests might miss.

Having a great suite of regression tests brings great confidence for a team of developers - who are often frankly a pessimistic lot - that can mean you and your team will stand out in the crowd and separate the true engineers (who care about delivering a quality product) from the cowboys.

(p.s. Thanks to Rick for the push!)

It does not take a Superstar - Developer types enumerated

2008-03-29T06:23:00.009-04:00

As someone who more recently has taken on more of team lead duties (*cough* project manager *cough*) I've had to reflect on how to dole out tasks and my success (and some failure) at this has really caused me to refine my understanding of different developer types I've known over the years.

So I've tried to enumerate different types that probably many of you are familiar with. These types probably don't 100% encapsulate somebody - often you'll see a number of these types in one person, or one type might dominate at any one time.

Also I'll try to give each type a rough score on a few dimensions. Dimensions that help me to assign tasks or pair people together.

1) Gets-it-done: Can be relied on to get the job done, fix the critical bug and will work with whoever it takes to do so.
2) Plays-well-with-others: the phrase "team player" is over used. I'm just talking about someone who gets along with others, who people like to work with.
3) Bugs: How many bugs in their code? How serious?
4) Code Quality: Is their code readable? Extensible? Good unit tests?

and I'll rank each types on these dimensions as: fair, good or excellent

Ok so here goes

Type #1: The Communicator
This is the developer that has great communication skills - speaks really well, listens and writes well. They can communicate complex topics easily and also they're great to pair up with business analysts/product managers/business folks to help tease out requirements. Very valuable when you need to have someone work with other teams. Good code but not the greatest but often it's readable and extensible and well thought through.

Gets-it-done: Good
Plays-well-with-others: Good to Excellent
Bugs: Good
Code Quality: Good to Excellent

Pairs well with "The Grouch" (see below).

#2 The Diva
This is the person who can just blow you away with the amazing product they create but boy do you have to massage their egos and keep them happy. In a crunch when things *must* get done you're just not sure which side of them is going to show up.

Very valuable often in the creative design or prototyping phase when they can come up with fabulous things no-one can think of or no-one thinks is possible. On the downside, they often have a surprisingly high number of bugs often which they attribute to the (lack of) intelligence of the user.

Not someone that works well with other teams! And if they don't respect your technical acumen - BOY! will they try to run roughshod over you. And God forbid you give them a deadline or pressure - the moaning and complaining and drama! AAGGHH!

Gets-it-done: Fair-to-Good
Plays-well-with-others: Fair
Bugs: Good
Code Quality: Good (not as good as they think though!)

Often Associated with: The Genius.

Side-Note: What's really funny is when you've got TWO divas on your team. They really tend not to like each other. Ironically because they think the other one's insufferable. Oh boy!

#3 The Genius
This is the one that knows the technology platform inside and out. They can come up with great solutions. But too often they come up with great solutions that no-one needs and/or the solution just doesn't work well with other teams' work.

They have great code - unit tests, readable, extensible, little duplication. Low numbers of bugs but when there are bugs it's usually a *huge* one that suggests they really didn't think through how their work would be used.

Their throughput isn't great as they tend to overthink things - so those huge bugs might take a week to address even if it's blocking everyone. They're similar to the "Diva" just without the drama and they're pretty level headed. Also similar to the Diva they don't work well with deadlines. They also have the nasty habit of checking in major things right before everyone else's deadlines - and then the fire drill that ensues . . . . . . . sigh.

Gets-it-done: Good
Plays-well-with-others: Good
Bugs: Good
Code Quality: Excellent

#4 The Fedex Guy or Gal (a.k.a. "The Savior")
When it "absolutely, positively has to be there overnight". Reliable, solid people with good code, little drama. Just gets it DONE. Period. This person is the savior for the team lead or project managers worst moments.

Often plays well with others, may not be the best communicator and has a fair few bugs but you don't really care because they fix them so fast. Also when it's fixed it's FIXED! May not be the smartest one or the most creative but they don't need to be - they lack the drama and often are good learners too. Good to pair with a "Diva" or "Genius" as this person is often more practical and will fix critical bugs fast.

Gets-it-done: Excellent
Plays-well-with-others: Good
Bugs: Good
Code Quality: Good

#5 The Grouch
Entrenched in the organization often through many years experience. They have some knowledge or skill that you just don't think you can replace. Not necessarily a bad or nasty person. It's just they're grouchy - you don't want to ask them a question or give them a task.

They get the job done and don't cause too much hassle outside your team. They fix bugs reasonably fast but often the code is unmaintainable or unreadable (can you say "Job Security"?) and they don't want to listen to you about FindBugs or Unit Tests or things like Refactoring - yeah that class with 40,000 lines of code looks GREAT!

Gets-it-done: Good
Plays-well-with-others: Fair to Good
Bugs: Good
Code Quality: Fair to Good

Good to pair with "The Communicator" who might be able to help smooth out rough edges.

And then there are a few types that we'd all wish we didn't have to talk about but often must deal with . . . . . .

The not-so-smart one
Ouch, you wouldn't have hired this person if you had interviewed them but often you inherited them. They don't want to learn. try-catch-finally blocks scare them. They use arrays because they learned them in C and learning about a Linked List seems unnecessary (and they just love fixing ArrayIndexOutOfBoundsException).

They're just not interested in staying current or learning from others. Usually every problem is someone else's fault or someone else's responsibility. Their solutions lack any creativity or planning. They're just not cut out for this.

Gets-it-done: Fair
Plays-well-with-others: Fair
Bugs: Good
Code Quality: Fair

The A-hole or The Bully
Yes this happens. This is the developer that throws everyone else under the bus. Often associated with "The Genius" or "The Diva" this is the one to be very wary of. If you share a boss in common you're going to need to keep your ear to the ground to make sure they're not throwing YOU under the bus.

They're often tolerated because they're really smart or they work in a culture of blame and backbiting where it's tolerated. Often it's wise to have a network of friends in your workplace who look out for each other - usually this guy (and let's be honest it's usually a guy) can be sidelined if lots of folks stick together. Another approach is to befriend this person. Really listen to them and try to bite your tongue. Get their opinion on things (as they're often high on themselves) and pretend like you care about it :-) Then they'll often go after someone else.

Also don't email them anything - they'll twist it and use it against you. However you *must* reply to them if they attack. Which they do. The hard part is when they attack without you knowing.

As the team lead I will go 110% out of my way to defend myself and my team from these ones. Boy do they irk me. Best of all they try to throw their intellectual weight around. I *love* when they try to do it with me - try, just try! Oh and when they screw up (no-one's perfect remember) the payback from all the other teams - WOW!

When they leave or are fired there's a palpable sense of relief across the organization. Often your boss knows all this well enough - they're just looking for the right opportunity to replace or neuter this one.

Gets-it-done: See Diva/Genius.
Plays-well-with-others: Awful
Bugs: See Diva/Genius
Code Quality: See Diva/Genius

Clearly this one generates a *lot* of emotion with me - people deserve to work in a respectful work environment. It's hard to hire a good team and then people like this make developer's lives miserable and want to leave. That's bad for the team and bad for the organization as a whole.

Wrap-up
The biggest conclusion I've taken - and a big surprise to me - it doesn't take a Superstar! In fact I don't think such a person exists. You've got different people with different skills and personalities. No-one's got it all. Although you might think you do *cough* Diva *cough* :-)

Often you get great productivity and great product by the right pairings - the Diva with the Fedex guy/gal. The Grouch with the Communicator. As long as they're WILLING to get along you can really pull together a great diverse team of people whom it becomes a pleasure to work alongside.

How to file a good bug report

2008-03-15T13:16:00.007-04:00

One of the first lessons, hard lessons, you learn coming into the world of software development out of college is how hard it can be to understand bug reports.

Variously they can be vague, misleading, inaccurate, confusing or best of all - misunderstanding a feature for a bug (the latter often points to usability issues).

Having endured many of these and now doing a fair bit of testing of my current application, I try to "be the change I wish to see in the world". So I've come up with the following scheme for bug reports.

#1 Start with a good short bug summary
For example:
"Data Entry screen disappears after entering certain unusual keystrokes"

The good part of this is a manager / team lead gets a quick idea of how serious this issue is (screen disappearing - bad!) where it occurs (data entry screen) and what caused it (unusual keystrokes). Useful in understanding just how serious it is and how soon it should be reviewed and/or fixed.

Next up you need to focus on the needs of the developer - basically instructions so the developer can reproduce the issue

#2 The *exact* build you are using
e.g.
March 27th 18:05 PM

Sometimes developers get dupe issues with related if not similar symptoms and having the exact build they can often realize "Hey that's that same issue I fixed yesterday" and they can then tell the tester - try the 28th build because it's related to issue X we resolved.

#3 Environmental Aspects
Including
- What machine the different parts of the system were running on e.g. web server, GUI etc.
- What database you were pointing at and DB login if appropriate
- How you installed the build e.g. options
- Your GUI login if appropriate
- If you can, it's really awesome to leave that build around and up-and-running so a developer can come over to your area and check it out for themselves. Not always possible but for those big critical issues it's a real time saver.

#4 Instructions to see the bug
The steps need to be detailed, step-by-step.

Often when I report a bug I spend a few minutes trying to get the least number of clear steps to reproduce an issue. This is important not only for the developer but for the person who subsequently tests the fix perhaps minutes, day or even months later.

You don't want to be too detailed "point your mouse to the 'Send' button and left-click" or too vague "enter some data and hit 'Send'"

1) Login to the GUI
2) Go to 'Tools > Data Entry > Advanced'
3) Select the 'Schedule' tab
4) Enter '03/04/08' and then without saving try to tab off
5) You get a System error (see attached)

5 Supporting Documentation
Screenshots are great 'proof' - especially for those developers you may know, who try to reproduce the issue for 5 seconds and then say "Unable to reproduce" and cancel your bug which you spent quite a bit of time entering. Very annoying!

Some folks who have long complicated steps often choose to add video capture too which is great (but bulky).

Logs are great too especially when they contain more useful errors related to things the developer can grasp e.g. Malformed SQL on line 223 of DataEntry.java.

Often these are attachments and as a technical lead I often trawl through the logs to find the most important lines e.g. often the first stack trace and then copy-and-paste that into the main bug description.

Other things you need in a bug report
- A unique identifier for this bug report
- Priority - Stick to High, Medium and Low - beyond that lies madness! :-)
- Severity is optional - often I find it confused with Priority for various reasons- again three levels should suffice - major, moderate and minor/cosmetic
- Who created the issue and when?
- Who is assigned the item?
- Who is the tester going to be?

Good bug reports take time. But it's worth it - I figure for every minute I put in to the report to make it clear and concise I'm probably saving 5 to 10 minutes of a developer's time and then more for the person who might have to test it (might be me 6 months from now).

As a team lead also I'll reject reports that lack these details. It's funny I've known some experienced QA folks who just can't seem to get this right - it's very frustrating to start a back and forth - which builds is this - please add logs - can you add a screenshot?- and then there are some who write them so well it just becomes a slam-dunk for the developer. Often they're the ones sitting right beside the developer - they've each learned how each other works - how to keep each other productive and keep frustrations to a minimum. That's good all around.

No surprise here - offshoring losing popularity

2008-02-27T19:59:00.006-05:00

So the worm has turned eh? Offshoring of IT jobs is losing it's popularity.

"Among respondents whose firms previously had ceased offshore operations (61 respondents), the most popular reason cited for doing so was that the operations required too much management and close oversight. Additionally, 30 percent of these CIOs believed that they weren't realizing expected cost savings."

I can certainly attest to that - software development is a very interactive profession - so much of what we communicate never gets written down, much is communicated informally at the water cooler etc. When a person is not "on site"- whether they're in Boise or Bangalore the job becomes more difficult.

I've been on both sides of this - having a client in Ohio while my team and I worked in Boston was pretty tough - being in person was so much easier. Also I worked for a large mutual fund firm on a project where half the team was in India. We did weekly video conferences and bi-weekly 6.30am phone calls. It was hard! With the shortage of IT workers now in India (since everyone pretty much outsourced there at the same time) we found it very hard to hire (and impossible to retain) senior developers. Being the architect I felt I had to step up and that was fine but the other local developers found it a burden.

The really hard parts were cultural differences and inevitable misunderstandings but most of all the time difference was the most frustrating. With almost 24 hours between responses (you write an email at 9am EST, they won't answer it until, say, 10pm but you won't read it until 9am the following day) it's hard to keep momentum especially on critical issues.

More than ever these experiences taught me that keeping development teams close together - ideally customers with management with developers with architects helps get to success quickly.

Offshoring won't go away and I don't feel it should - I really enjoyed the intercultural and travel opportunities - but this just points to those "bean counters" who think software development is like "brick laying" or something that scales well when you add people - you just need bodies in seats - the cheaper the better.

It's NOT! Perhaps we should buy them copies of The Mythical Man-Month

10 things Project Managers wish Developers understood

2008-02-18T12:38:00.023-05:00

Well I've been very busy the past few months - most of it adapting to a new role as a Project Manager - technically I'm called a "team lead" or a "director" or a "senior manager" - depends who you ask, but when it comes down to it I manage the dev team to a project plan in cooperation with a product manager.

Being on the "other side" now for a while it's been a real eye-opener. It's definitely true that it's hard to relate to someone until you've walked in their shoes for a good bit. Having worked with project managers several times before, I've always wondered about why things were a certain way - ways I thought I would have done things differently.

Well not anymore - now having "walked the walk" I thought I'd blog about the things that most developers on a team won't realize until they are the person in charge.

10) Information Overload: I wish I could focus on one thing at a time but I've got a million people coming at me from all directions.
There's product managers, support, management, customers with their needs, developers, other team's manager, architects and developers. That's a lot of relationships and information to manage so don't be surprised when you encounter the following type of interaction.

Developer: So, you remember that issue with the GUI last week?
(subtext: that really critical issue I finally figured out the solution to?)

Manager: Which issue is this?
(subtext: I just spent three hours replying to emails to 14 different people and I'm wiped)

9) Work Pressures: The Manager can get too excited or stressed by the pressures and try to "tell you the solution". Push back (gently) if it doesn't make sense.
When you're the manager and don't code - you get all the responsibility (worry) about meeting the deadlines but very little control over it.

Those managers who have spent time as developers sometimes like to think we can just give other developers the answer. But that doesn't work - developers are a creative and (for better or worse) egotistical bunch (me included) and we want to impress our bosses rather than just take orders.

I've learned to ask guiding and information-seeking questions rather than suggest solutions e.g.

"So how many files are impacted by this change?"
"How will this SQL change impact performance?"
"How will the GUI change impact our key user flows?"
"So if we fix this bug, what are the odds we might break something else?"

8) Project Risks: New technology = Risk
Anytime you kick off a new big project, developers love to use new technology - but the effort can't all be about new technology - with new technologies come risks to the project. There may be efficiency gains but do they outweigh the risks?

I've had managers who just said "No" to new technologies, but they didn't understand the desire of most developers to improve themselves and learn the hottest new technology (e.g. Ajax) / framework (e.g. Spring). It was so demotivating. Also there's often some productivity gains to be had from trying new technologies so it's a short-sighted idea to adopt a blanket "no".

I've also had managers who only said "Yes" and then the project got bogged down in technical issue after technical issue and didn't deliver the functionality anywhere near on time as the developers had a large learning curve (or several curves) to overcome.

As a developer I understand how developers love to learn - but as a manager I have to balance the motivation of my developers with the goal to deliver a functional product.

7) Productivity: The best managers insulate developers from the craziness that goes on in middle management - bad specs, crazy ideas, changes in priority, too many meetings.
You think your pointy haired boss is nuts - you should see the people he/she works for! :-) The problem with modern day software is there's so many teams involved - the dev team, the QA team, support, client relationship, consulting and everyone's got their own viewpoint, their own goals etc. They see either bigger pictures or completely different pictures entirely.

Some developers have some idea that this goes on - if you do thank your boss - they're buying you time to be productive and do the things you love - Code!

6) Capitalism: The reason this company exists is to make money - sometimes you have to do some apparently silly things to get the money.
Customer's aren't always logical, they have their own goals, their own viewpoints (seems to be a theme here). Sometimes the Sales folks have to commit to things to get the deal. They sound reasonable enough unless of course you have to implement them!

Yes you have a right to be ticked off at folks who oversell - but then again the company you work for is (hopefully) there to make money. The Sales folks are the "rainmakers" so the best you can hope for is to build a constructive relationship whereby they consult with you about what's possible and what's a stretch.

5) Doing the things we don't like: We have meetings because they're needed
I know meetings interrupt your favorite activity - coding - but they really can't be helped in some cases. I need to know that you're aware of what's going on - frankly I have very little insight into how things are going until things are nearly done.

Fortunately as a now sometimes-developer I use tools like FindBugs, PMD, Checkstyle etc. to check on the code and use Unit Tests and Code Coverage to see how's the quality roughly holding up. But all those are proxies for the real thing - the quality of the product from a user's perspective.

So how else can I quickly get to know how things are going - meetings. Sorry!

4) Information Overload II: I can't be expected to remember EVERYTHING.
I forgot we promised to meet to talk about "that" question. I wanted to put a reminder in Outlook but I got interrupted twice and then I was called to my boss's office - I forgot. Be gentle on your manager - they're really trying (or should be) - if I make a mistake let me know. Keep us in the loop - just find the right moment.

3) Information Overload III: Hold off on the details - First tell me why I should be concerned
Developers come in all shapes and sizes - there are the ones who bottle up all information, stay heads down in the cube and only come out when they're done. The scary thing there is you don't know they're done until . . . . well . . . they're done. I can manage that one pretty easily - I try to "ping" people and check-in. Hopefully not too often.

The other side are the developers who think you want to know every piece of minutiae and that you understand the impact - for example:

Developer: "So you know that new Finder class team X implemented? Well they created a new Factory method which isn't thread-safe. I mean they're nuts don't they know that our thread pool will etc. etc. . "

Manager (who was deep in figuring out critical dependencies in the project plan): (thinking) is he gonna think I'm a moron if I say "Huh?"

It's better to say what the impact is and hold off on the details e.g.
"I think our new multi-user scenarios are going to have some problems with the new code from team X".

That gets to the point (there's a problem) and stops me from having to think too hard (why should I care about thread safety in a particular class) - you should be able to tell from the smoke already coming out of my ears? :-)

2) It's not all about you (the developer)
I was guilty of this one for a while when I was just a devleoper. I really thought that of all the issues faced by the team mine were the most significant. I'd get peeved when issues I felt were important were being ignored. But the reality was I wasn't aware of many of the points listed above. Wow, perspective is everything.

1) It's good to be the King
No it's REALLY good :-) Previously as an Architect or lead software engineer I had a position of influence but little power. Now I have people reporting to directly to me. I control their reviews, their raises, how much they work and how late, which project is next. I still consider myself an "Architect" at heart and I love being in the code - but it's nice; knowing the technology, how developers are often motivated etc. and now to finally REALLY have a big say in what gets done and how.

For example, there's some really complex code we've written lately - quite fragile unfortunately due to it's (necessary?) complexity. As the developer I probably would be too lazy to write the full set of unit tests or wouldn't have the time. As the architect I'd know that we need to do that but very often I could never convince the project manager to let the developer spend the time. Now I'm project manager and can read the code coverage numbers as well as know many of the user scenarios.

So I had the developer write about 40 unit tests covering a very comprehensive range of scenarios. It took about a month to get them all done (ouch!). But in the process we actually found three new bugs. Ultimately though we've mitigated a lot of risks that were in that component.

Now when new bugs come in from the field or from QA, we fix them more quickly and then we can quickly re-run the unit test suite. We also add unit tests for that new test case we just discovered. Now I as a manager I know when the unit tests run green - that despite the code complexity, we're in pretty good shape from a risk/quality point of view.

It's a balance of course - we've discovered more unit tests we need to write for this component (based on how our users are using it in beta) but we're under the gun for the next few weeks in another area so we'll get to it - but not yet.

It's also good when it comes to hiring time - too few managers know how to spot a good developer - having been a developer and spent a good deal of time on screening questions and interview techniques I feel that I and the team are pretty good at identifying strong folks. I usually do the screening so that the developer's on my team only spend time interviewing really strong candidates who don't just "talk the talk" or have keyword-heavy resumes and don't really have the talent to back it up.

Postscript: I'll also write an article coming from the other perspective - things that developers wish managers knew.

Agile Programming in a nutshell

2007-11-27T19:37:00.000-05:00

See this Link

When Dilbert mocks you, you know you're mainstream! :-)

My Favorite Java and Software Engineering Articles

2007-08-24T22:26:00.001-04:00

Here they are - a collection of quite a number (250+) of the many online articles on Java, Software engineering (architecture, the development process), XML etc. that I've read over the last years - probably going back to 2001. I've included a URL and a personal score (on a scale of 1 to 5 with 5 being awesome).

I hope you'll find this useful - some of these articles took quite a bit of digging to find but were well worth the effort.

http://spreadsheets.google.com/pub?key=prCSPRhj1PCGuYZvjEITgXw&output=html

Please feel free to shoot any comments, edits, suggested additions (or deletions?). Because the underlying spreadsheet is on Google Docs (love it!) it will get updated on a semi-regular basis as the reading list continues to expand.

4 reasons it sucks to be in QA

2007-08-06T20:46:00.000-04:00

Well that's my take on it folks - of all the roles in the Software Development Life Cycle probably QA has it worst. Managers, Architects, Developers, Business analysts - no-one takes as much BS or has such a thankless role as the valiant folks in your average QA team.

Now I hope most of you reading this will disagree but I'm betting there's a lot of nodding heads out there (probably mostly from folks in QA).

What are the main reasons for this you say? There are four as I see it:

1) Respect
QA tends not to get respect from people in other roles - but most especially and most oddly the least respect (most disrespect) comes from software developers. Personally I find this strange that developers have such disrespect (sometimes even open and outright disdain) for those tasked with ensuring the quality of the product being delivered.

I think a lot of developer frustration comes from the questions and problems that arise out of the QA team/group. Yes, often QA folks don't understand the ins and outs of an application. If that's because someone in QA doesn't want to learn then that's a worthwhile beef but more often than not the QA team are STARVING for information.

Often they're brought in at the last minute, given a vague, incomplete and out-of-date spec and told "Hey go test this!". Yes the developers had the same spec and were told "Hey go code this!" but they're finished building out the app so they've (hopefully) fleshed it all out at least in their heads and in the software they've built.

Developers deride the QA role - "What do those guys know? They're just testers!".

That's just the wrong attitude. These guys and gals are the ones who, at the least are helping to make the product (not code folks - product!) better, and at best saving your ass from being fired for shoddy work. You and they are on the same team though you may not realize it. Try to remember that.

Another reason that I feel developers beat on QA is that the developers get beat on themselves (think Dilbert) and like some bullied kids they look to take it out on the only one's they can - someone weaker - not managers, not architects, not the business analysts, not other developers - who's left? QA!

I've seen it many-a-day - the self-righteous attitude developers take in correcting QA or better yet informing them that their "bug" won't be fixed because it "works as designed" or they spent 5 seconds trying to reproduce the bug and could not.

I'm not saying "works as designed" or "unable to reproduce" are a bad reason to kill a bug - just the attitude that goes with it. Call the tester - explain why it works that way - should the docs be updated to make that clear? Possibly! If you can't reproduce a bug maybe there's some context or other missing information - maybe it's particular to the tester's environment. Just blowing things like that off might make a developer feel good but it diminishes the overall product and the team too. Take the time to do it right - a phone-call or walk-by will take 5 minutes at most.

2) Responsibility vs. Power
The QA team have a very important responsibility - they are the gatekeepers of product quality. At least in theory anyway! Also quality is a hard thing to identify or quantify. Is it the overall user experience, the number of bugs, the number of critical bugs, how do you define "critical"? Just too many subjective things. Oh and usually they're understaffed and/or under-tooled.

However for all this responsibility they have the least power. In the hierarchy of management structures QA comes pretty much last.

Everyone else thinks they can do the QA job - how hard can it be? But the reality is very few people can do QA right. And especially not developers! We are our own worst enemies in this case - we use the application like we coded it not like it was meant to be used.

3) Last to be hired and First to be fired
In the boom and bust cycle of software QA folks seem to be the last to be hired - usually towards the end of the boom when all your new customers start to complain about the bugs from all the newbies you hired at the start of the boom. But then when the bust inevitably comes QA folks are first on the chopping block followed by middle managers. No wonder there aren't many experienced QA folks about - again it's a widespread lack of understanding of the importance of QA and testing in the software process.

4) Paradox of excellence
The "Paradox of excellence" is something we're all familiar with but may not know it. Since the art of software (it ain't engineering or science yet) is not well understood, few outside of software can understand how hard it is to do software "right" - with few bugs. It takes a long time. Therefore when software is done right people don't perceive the absence of bugs - they just see that the process seemed to take forever to complete.

Basically the "paradox of excellence" states that you don't get credit for problems that never happened. Typically in the normal software shop when bugs happen and they are fixed fast by developers the developer gets kudos. Who gets kudos for the lack of bugs in a release? No-one.

So if QA does their job right - no-one notices. The same is true for developers to an extent but they can usually redeem themselves if and when bugs do show up. QA have no such opportunity - if they *do* spot issues they becomes "spoilers" for the party giving the bad news no-one wants to hear.

With those four issues facing you as a person in QA - lack of respect, little power, no praise, fear of being laid off, how much motivation would you have every day?

In my opinion a rock solid QA person is one of the most critical roles on a project. In fact in my experience the best QA people know the application better than the developers, the managers, the analysts and even the users. They know the ins and outs - breadth and depth and know where most of the bugs pop-up! I wish most developers were so aware.

Solutions?
How do we resolve this problem for folks in QA? There are two steps - the first easy and the second not so much:

1) Co-locate QA and Developers
Have developers and QA sit side-by-side and work together closely throughout the entirety of the software lifecycle. Make them truly part of the team! Have lunch together!

Physical separation of QA from the dev team is a bad idea. Having separate reporting structures for Dev and QA might be good since having same reporting structure creates a little "conflict of interest" - management understandably want good news, QA are rarely bearers of good news - but it's news that needs to be heard!

2) Developers and management need to snap out of it!
Frankly this treatment of folks in QA is one of those little "secrets" in software that we should be ashamed of if we consider ourselves to be "professionals" in the true sense of the word.

Developers and management need to respect the critical role of QA, the complexity of their job and most of all to drop by their cubes and say thank you for all their hard work they do without much praise - day-in, day-out. Your product is better for it, the industry is better for it (and could do with much more of it) and thus the rest of us managers, architects and developers are better for it.

Another Google first - missed estimates - hiring to slow - share price drops 7%

2007-07-19T21:39:00.000-04:00

Looks like Google just missed analysts estimates on EPS (see article here).

Key Quote

In the conference call, CEO Eric Schmidt admitted that one area the company exceeded its expense plan was in hiring, which added more than 1,500 workers to the payroll during the quarter. "We are very pleased with the talent that we've brought on board, but going forward we will watch this area very closely," he said.

This is one of the key downsides to being a public company it's very hard to "surge" and take some time to build now for the future by hiring as many great people as you can.

That said with every other measure (revenue, operating income etc.) on the up-and-up Google is the still the one to beat.

In other news it looks like Yahoo! is having a very tough time and now there is talk (again) of Microsoft buying them.

Are Agile methods detrimental to your design?

2007-07-19T21:11:00.000-04:00

InfoQ has an interesting article entitled Are Agile Development Practices Detrimental to Architecture and Design?

I've said it before and will say it again TANSTAAFL - There Ain't No Such Thing As A Free Lunch (with thanks to Robert Heinlein). You can't expect to suddenly change to run an Agile project (e.g. using Scrum / XP) and expect miracles - that is a gain to your project without any associated pain or cost.

My feeling has always been that with Agile development you need quite senior people who can run the project fine without the heavier and better known "structure" of traditional processes. Also you'll hope that they'll pay attention to key architectural and design issues without a traditional BDUF architectural or design phase.

But regardless of the type of process you choose (BDUF vs Agile) there are three people (or three roles) you need on your project for long-term success that is release-after-release year-after-year.

You need
1) Someone who knows either the vertical area (e.g. Financial Trading Systems or the Retail sector or Cell Phone advertising) and where that field of expertise is going (e.g. more analytics for trading systems, SaaS / ASP models for Retail).

You also need
2) Someone who knows the users and their likes / dislikes ( e.g. they like responsiveness and dislike overly flashy apps but may be amenable to Web 2.0 technologies such as twitter more easily) also if there are any key users to watch for (e.g. head traders or your CEO's best friend!)

And finally
3) Someone who understands what all of that means for the Technical Architecture and Design
and who can create a roadmap to get there . . . . .

Where do you find such folks on your team?

#1 and #2 are typically Product / Project Managers / Business Analysts
#3 is typically the "Architect" / Technical Team Lead for the project

The key value to Agile is getting to market quickly - combine that with talented senior people who are good at numbers 1,2 , and 3 and you've got this key architecture/design issue mitigated to a large degree. That said, it does depend on the little issue about predicting the future accurately! But so does all software architecture and design.

Forget SQL Injection you need to watch for XML Injection

2007-07-19T21:06:00.000-04:00

With all the XML flying around these days (SOA, ESB and Ajax) you need to be ever more vigilant.

Check out this article from DeveloperWorks entitled Avoid the dangers of XPath Injection

Now more than ever validate your inputs!

A little Java puzzler

2007-07-13T18:01:00.000-04:00

Alright here's a little Java puzzler - not on the order of Josh Bloch but still I'm surprised how such a simple problem can give me such a headache . . . . .

I know several ways to solve it (probably those that are the most obvious ones) but I'm hoping others can see a more elegant / less hacky solution.

(Perhaps there's a really embarrassingly obvious answer but after several interrupted nights of sleep due to our newborn I'm just not seeing it)

The issue at hand is we want to perform a business operation and keep track (in memory) of the job's state. It's not critical that the job succeed but it is ABSOLUTELY critical that we record the state of the Job correctly.

So first off here is some pseudocode:

Set Job Status to "New"
Start Job
If job fails set status to "Failed"
If job succeeds set status to "Success"

Simple right? Well the problem comes in when you have exception handling so here's a quick first cut of the code that I wrote

Version #1

Clearly I'd want to store / log why things failed but let's not worry about that for the moment.

Anyway so that's pretty simple, and looks correct, but wait - what if an unchecked exception is thrown. I really don't want to catch RuntimeException (let's not even thing about catching an Error / Throwable) .

So perhaps I add a finally block - so that if the status is still "NEW" then clearly an exception was thrown that was not the Checked exception.

So here's Version #2

But that looks so hacky and also someone reading the code is really going to have to think about it to see if all paths are appropriate (as compared to the pseudocode which is "obviously" right).

True I could mimic the pseudocode outlined above and catch any exceptions in the launchJob() method (including RuntimeException?) to get code as follows:

Version #3

but perhaps as the caller of launchJob() I am not aware of the catching of all those Exceptions (including Runtime?) in the method (say it's some vendor / 3rd party / external API) and so I go back to wrapping again but this time without the catch block

Version #4

A little cleaner but still - the pseudocode is the cleanest of all - why can't I map it to Java more easily and not worry about possible Exceptions and the resulting ugly code?

Thoughts? Suggestions?

(p.s. this problem highlights for me one of the key issues developers must face that isn't talked about much - not just solving the abstract problem - for me the solution to that is the pseudocode - but here the hard issue is mapping the solution to a language and understanding the behavior of that language - exception handling, how unchecked exception work etc.)

Java Worst Practices

2007-07-04T11:02:00.000-04:00

We've all read those "best practices" articles which are great and useful. But after the good reaction to my "Java Exception Handling Anti-Patterns" article I thought I'd continue on in the same vein - things NOT to do.

So here's a list of "worst" practices - the things I see many-a-day that are particular pet peeves of mine. Frankly I've made these mistakes myself quite often when I was less experienced so they've become a kind of personal checklist for my own code as well as for that of others. I've touched on some of these issues before but have added some more and drilled-in a little more.

Of course these days I use my code checking tool trifecta (Checkstyle/PMD/FindBugs) to do it faster and more reliably but still it's good to stay sharp and do it manually every so often.

1) Exception Handling I: poor catch blocks
See the blog entry "Java Exception Handling Anti-Patterns" for a number of such anti-patterns. How to handle errors correctly is critical and not altogether that easy in Java (thus the whole checked vs. unchecked exceptions debate IMHO)

2) Exception Handling II: missing or bad finally blocks

If a finally block is absent in a try{}catch{} combo, is one needed to release resources?
Is there an exception thrown in the finally block that bubbles out? Talk about cause for confusion when reading the code!
Is there a return inside a finally block? Talk about even more cause for confusion!
Do you have returns *AND* uncaught exceptions in your finally block? Check this link out. Exceptions that just disappear into the aether? Yikes! I'd guess 90% of developers (including myself) got that wrong.
If there are multiple methods called in a finally block, and any of them can throw an exception, will the other methods get called e.g.
.
.
}
finally{
try{
if(obj1!=null) obj1.close();
if(obj2!=null) obj2.close();
} catch(SomeException ignored) {
}
}

In this case if an exception was thrown when closing obj1, then obj2 would not be closed creating some problem such as a memory leak.

3) Logging

Too little? App crashes and there's nothing in the log file.
Too much? App crashes and you need to plow through a 5 GB log file (just for that day!)
Wrong level - debug vs. info vs. warn vs. fatal?
Same log entry repeated many times
Using Exception printStackTrace() - Do not use printStackTrace except for the simplest programs - use you logger and log.error("Some Text Here",e); to log that important and all-too-helpful stack trace information information to your log file for posterity.

4) Classes / Methods too big
Big classes and big methods become inevitable complexity sinks - the code becomes very very hard to maintain. Create utility classes, break-up the functionality - do some refactoring to make it easier to use, extend, adapt and especially debug!

5) Comments in code

Too little?
Too much?
Comments which are no longer relevant or are out-of-date with respect to the code
Comments which are useless/redundant e.g.

//set number of accounts to zero
numAccounts=0;

FYI some best practices in this area are listed here on Wikipedia. Most notably:

Comment why not what - make your intent clear.
Make your comments the code - if your comments are clearer than your code make your code look like the comments.

For example here's a pattern typical of code I often find in a review (even of my own code)

//check system Ok for startup
if(switch1 && switch2 && (switch3 || switch4))

now replace that but as follows and drop the comment

if(isSystemOkForStartup(switch1,switch2,switch3,switch4))

now you've got a nice utility method that you can re-use plus one less comment which means one less place where you have to keep the comments in synch with the code

6) Switch Statements

Missing default: - just put something in there even if it's a log.warn("This should never happen");
Missing break; and the resulting "fall through". God those bugs can be nasty to track down.

I usually write the "default" first to make sure it gets in there and try to give visual cues to highlight missing breaks like trying to line them all up vertically.

7) catching java.lang.Throwable
There's a few cases where I think this is OK . . . . okay just one . . . wrapping a complete application with this so you can log.error() / System.out.println() if something bad happened that for some reason wasn't handled.

But apart from that, exactly what do you plan to do with VirtualMachineError or OutOfMemoryError? Just carry on?!?!?!

8) Using exceptions as flow control
Sigh! It still happens every so often.

9) Not removing commented out code or unused classes
I've done it myself but usually I open a bug report to myself to take it out (eventually). Sometimes it's hard - you've written some good code that you might use some day just not now and you want it in there - but hey that's what Source Code Control is for.

10) Complex code with no unit tests
Don't even get me started! Yeah yeah I know the refrain - we don't have time but come on - a few unit tests? Please!?!?!? Just some happy-path cases?

11) Duplicate Code
We've all done it - we just need to make sure we undo it - refactor! If you've got production code and 1 or 2 dupes I can make an exception. 44 not so much (trust me I've seen it!). Oh and the excuse here - "Well we've got 44 separate JSP files" - turns out it was really one JSP file with some parameterized pieces of code. About 5000 lines suddenly became 250.

12) In multi-threaded code, using Object.wait()
That is the call to wait with no timeout - so the user or calling application can just wait forever eh? Oh and the bugs it causes - your code just sits there "dead", there's nothing whatsoever in the log file and then you've got to find the one thread in your 500 with the endless wait.

Every time I get one of these I cringe, cancel family vacations, hunker down and get stuck in.

By using a timeout you force yourself to think about what is a reasonable thing in most cases - what if that shared resource is simply not available? If you don't do this, effectively you just expect "the other guy" to worry about giving it back and abdicate your own responsibility.

13) Coding Standards that are directly in contradiction to accepted and known Java standards.
For example - not only allowing class names to start with lower case letters but ENFORCING it (yup - been there)

14) Enforcement of Coding Standards that is overly picky
I could pick an example (e.g. placement of braces, tabs vs. spaces) but I'd probably evoke a bazillion flames! Oh and best of all - often these rules are enforced before important things like unit tests, code coverage - those things related to code that works!

15) Overuse of XML
For example - storing XML in a database and then wondering why indexing on the contents is slow?

16) Wrapping Java platform APIs
For example - wrapping JDBC with your own API. Now I'm not talking a DAO or some abstraction layer - I'm talking about a class-for-class, method-for-method wrapping!

Oh I'm sure there are others but these are the ones I look for during a human-based code scan. I can't scan my own code because I'm terrible at it (and lazy whenever I spot anything - just too easy to look at the other 10 things pressing on my To-do list). The best thing to do here is use Checkstyle/PMD/FindBugs and have someone else prod me.

Wanted: CTO to bang out some code

2007-06-29T20:42:00.000-04:00

Recently I've been surprised at job postings for Architects that also expect the person hired to double as Project managers or Product managers (or both) in addition to their architectural duties as well as being a developer for a chunk of time too. I hope the pay is good for your 90 hour work week!

And then I saw this ad - the emphasis is my own
(here is the original link - but as with most job sites it won't stay active for long)

"Chief Architect (CTO role) - Agile, SOA . .
IMPORTANT: Strong preference given to candidates from eBay, Amazon, Microsoft, MSN, Google, Yahoo, Netflix, other large ecommerce or software product companies . . . . . Must not be too high-level and still able to code and mentor Engineers. Will also have led large teams, and influenced/impacted even more people through their thought leadership.

This is a Chief Architect role that is at a CTO level! In this role, you will lead a team of hands-on architects in envisioning, building, and evangelizing the companys IT technology strategy. Their greatest challenge will be to harness the creativity of their agile development team and direct it in the disciplined pursuit of their aggressive business objectives. With the goal of meeting their business objectives, you will create and lead the execution of a multi-year architectural roadmap for their growing portfolio of software and hardware."

I don't know about you but if I was a CTO / Chief Architect / Enterprise Architect at eBay/ Amazon etc. I'd stay a million miles away from this company - IMNSHO they're really not sure what they want. I mean this is a CxO position - and they want the person to lead architects, mentor engineers and still code. Wow! Perhaps they should look for one who can also be administrative assistant and janitor too?

What do you think? Is this a reasonable request? This is a bad smell to me - someone high-up in the food chain either doesn't really know how software teams work or is unaware of the expectations for what a CTO does at any company bigger than 50 people.

How to spot the dreaded non-coding architect

2007-06-29T20:09:00.000-04:00

(Could this be flamebait - probably! But here goes anyway)

By Architect here I'm not talking Enterprise level folk who pretty much don't code much anyway - they're really IT strategists and don't need to apologize. I'm talking about the Architect for a small division or one team or a small number of teams not entire divisions of people with over 500+ developers.

Non-Coding Architects (NCAs) are also known as "Ivory Tower Architects" or "Astronaut Architects" or "Powerpoint Architects".

These NCA folks can be really quite dangerous and give dev teams a bad name - pretty much as any leader who really doesn't have the ability would hurt his organizaton. In addition, one general trait of NCAs that I've observed is their tendency to criticize the work of others to ensure the spotlight of accountability is off them. Either that or they can spew so many technical and complex terms that you're not really sure what they said - but the sounded smart so you're happy to have them on the team. Right?

The developers know these guys (or gals?) couldn't code their way out of a wet brown paper bag - the problem is no-one else can see this so typically the developers have to suffer through the bad design decisions that inevitably result.

But how can you spot one? For most developers it's pretty easy but just in case you can't I've compiled a list of example scenarios that should help - comparing the often dogmatic attitude of the NCA with the pragmatism of the experienced Coding Architect (CA).

Scenario: Need to map an object data model to the database
NCA: According to the J2EE spec we should be using Entity Beans.
CA: Entity beans are terrible - let's write our own DAOs or use Hibernate/iBatis/Toplink. Why do we need an App Server for this? Let's try to stay with J2SE.

The essential issue: J2EE Entity / Session beans were too slow and cumbersome for too long - you also need an app server (which cost mucho $$$$ if you go IBM/BEA). Why not use lighter frameworks such as Spring which will work pretty much anywhere? The NCA wants to adhere to the "spec" from Sun. The CA has been burned before and knows better.

Scenario: We need only one instance of an Class per JVM
NCA: Hey design patterns are cool - let's use a Singleton!
CA: How do I code thread-safe singletons in Java? How do I unit-test a Singleton? Let's try to avoid this if we can?

The essential issue: Design patterns are great - but sometimes the pattern is more trouble than it's worth. It's hard to code singletons right, especially for thread-safety. Also they're hard to unit test because singletons are stateful classes whereas unit tests should be as stateless as possible

Scenario: Users say our app is too slow
NCA: We need to create and perform a performance test suite across all our supported operating systems, and supported database platforms. We need to buy (insert your favorite expensive and unwieldy toolset here) and test all user workflows.
CA: I know where the bottleneck is because I live with the code daily - we keep loading the same static data over and over again. We'll do some analysis but at least this will get us most of the way.

The essential issue: These days you don't have the time! The first few performance improvements in a new application are usually easy to spot (if you work with the code daily). Some analysis though to verify your hypothesis is required though. Do those initial improvements first and then you can perform the full-blown analysis.

Scenario: Our CIO says we need to use SOA / Web Services now!
NCA: We should use the WS-* specifications
CA: You know the WS-* specs are still in development and somehow apps with Web Services and SOA are proceeding along fine - let's be careful about which standards we adopt and have a plan in place in case they change. Hey what's this REST thing? That's pretty simple!

The essential issue: Simplify, simplify, simplify! WS-* specs are just getting too heavyweight and are getting bogged down by vendors. Don't get locked in analysis paralysis or worse adopting so many WS-* standards your dev team needs 6 months of training before writing a line of code.

Scenario: We need logging in our application
NCA: We should use Commons Logger as our default logger
CA: Log4j gives you so much more useful functionality that gets abstracted away by Commons Logger - let's use that instead. Log4j's appenders are just soooo cool!

The essential issue: You log file is a very important artifact and you'll want to do different things with different parts of it (e.g. send emails on errors, log some stuff to the database, send something to a message queue etc.). Log4j lets you do that - but in most cases you need to use the XML configuration. Commons wrapper let's you use Log4J underneath but only with the log4j.properties files - you lose access to many of the cool appenders with pattern matching capabilities.

Scenario: Our J2EE vendor provides a useful non-standard set of functions - should we use them or write our own?
NCA: Let's make sure to write all our EJB code without hooking in to specific WebSphere/WebLogic etc. extensions. Let's stay vendor neutral. So let's write it ourselves!
CA: It would take us longer to write our own code to do this - so why not use the extensions and just ensure we wrap them in some facade / abstraction that doesn't leak anything container-specific.

The essential issue: Save time! Anyway, what are the odds you will switch J2EE app server vendors?

Scenario:We've got lots of code duplication
NCA: We need an AOP solution
CA: Just refactor!

The essential issue: AOP is cool - but do you have the time for your developers to learn about point-cuts etc. Anyway the problem isn't lacking AOP it's often laziness (or the absence of support for closures!)

Scenario: Architect is asked to speak to software developers
NCA: Use words such as "alignment", "leverage", "synergy", "the long tail", "thought leadership" and the latest buzzwords (SOA, Web 2.0, ESB).
CA: Use words such as "regression tests", "refactor", "reuse", "Keep it simple", "usability and easy of use"

The essential issue: Are you a managing up or managing down? Are you trying to be a Servant Leader and help your team whilst also helping management (they don't need that buzzword soup either)

Software Lifecycle phase - Requirements
Guess who is who here

"We need a full month of off-site JAD sessions to gather requirements" vs. "We need a paper/HTML prototype"

Software Lifecycle phase - Architecture
"We need UML diagrams for each class and interaction with Rational Rose" vs. "We just need to document key classes and flows - let's use Visio or StarUML"

Software Lifecycle phase - Design
"Let's do it this way" vs. "How should we do this?"

Software Lifecycle phase - Coding
"JDepend says your code needs to be more adaptable" vs. "JUnit says we need to fix some unit tests!"

Software Lifecycle phase - Testing
"Why did you do it that way?" vs. "How can I help?"
"Why is that broken?" vs. "You've got plenty of bugs on your plate. Let me fix that!"
"That keeps breaking? Why?" vs. "Yeah that's a troublesome piece of code - can we do any refactoring and perhaps add more unit tests"

I look forward to your comments and stories. I especially love the stories of Architects who really don't understand the technology and come up with the craziest ideas and the developers who save their asses (or not!).

Finally I have had it with Microsoft

2007-06-28T06:44:00.000-04:00

How web apps and OSS can help you kick the habit too

So last weekend I bought a new laptop on sale at CompUSA. It was a really great deal - powerful or so I thought until I took a look at Vista installed on it. It can't go back to Windows XP / 2000 as there are no OEM drivers for those OSs.

But, I thought, what the heck it's just for some basic "around the house" work - web and document editing.

But after a weekend of playing with it I've realized - finally - after 12 years (since Windows 95) that the Windows OS is not just failing to get better it's getting worse - "Do you wish to open this application" - "Of course I do I clicked the freakin' button didn't I".

It takes forever to shut-down and start-up - despite uninstalling the bloat-ware. Windows Media Player is almost useless for playing DVDs (missing codecs etc.)

Anyway I've been using Google Docs, Google reader etc. for some time so I'm not installing MS Office despite having access to an MSDN license and I'm ditching IE for Firefox (so many great tools for it).

I'll stick with Vista cos the Laptop is jointly being used by "civilians" who understandably don't want to be learning a new OS when Windows took them a decade to figure out. Anyway there's something to be said for knowing how to work around Window's quirks (or are they features?)

I've configured Vista to look more like Windows "Classic" as the Vista look-and-feel is just too busy - flashy - looks great - but I just want to find a file dammit!
And where has the "Open with . . . " right click option gone?!?!?!

AAAAGGGHHHHH

So it was fortunate timing that Lifehack had a recent blog entry citing a great Mashable.com resource

Replacing Microsoft Apps with Web Apps

(Here's the direct Mashable link)

a nice follow-on to another blog entry they had entitled

Top 10 Microsoft Alternatives

Now if only I could get a desktop widget to remind me of my Google Calendar entries I'd be all set.

Oh and BTW if you are not subscribed to Lifehack.org's RSS - do so now - it's got an incredibly wide array of productivity tips and advice every day - certainly the most useful blog I subscribe to and the one I read first (if pressed for time) and last (if I have lots of time and want to savor the anticipation of what they will teach me next).

Some people I'm sure are way ahead of me on this (switching to Mac OS/X and Ubuntu and totally have kicked the M$ habit) but I tend to one of the early majority when it comes to adoption of new technologies (sometimes I'm an early adopter if I can quickly see the benefit - typically via a good blog review from someone I respect).

10 Computing Questions I would love to know the answers to

2007-06-21T21:07:00.001-04:00

1) For Java/J2EE what's the most scalable server hardware platform?

OK, "scalable" is a pretty subjective word (and by scalable I guess I mean "scale up" not out) but say I have this incoming message stream (say JMS) of many tens of thousands of small messages every second (stock ticks for example) and have a single-thread (for arguments sake) and just want to read as many of them as I can.

Which server platform in its default configuration will handle the highest number per second?

In my experience the Sun server (Solaris) platform is the most scalable, linux (on x86) second and Windows (x86) third but with the recent advances in hardware how is that holding up?
I don't trust any vendor benchmarks (something about foxes and hen houses) or reputedly independent analysts who just happened to get a lot of money from the winning vendor.

2) Which Database does Google use to store data?

If it's a commercial RDBMS then how can they cram so much data volume as a whole into them, plus it's coming in like a fire-hose. In my experience modern RDBMS can handle at most thousands of transactions per second. But Google has to be many orders of magnitudes beyond that. We can talk grids, sharding etc. up the ying-yang but at some point it all has to come back together in some data store (or does it?).

3) When will Sun go belly-up?

Don't get me wrong, Sun have done a lot of great things - Java, Solaris, J2EE (OK skip that one), but they've never really made any money off of Java (like, say, IBM did), they still focus on hardware solutions over a decade after Lou Gerstner of IBM saw the money in services, never mind packaged software.

I guess they're the Xerox Parc of the 1990s / early 2000s - lots of great seminal ideas and too far ahead of their time - but just can't make any real money.

4) Feature-for-feature how does Oracle / MS Sql Server / DB2 stack up against MySQL / Derby / PostgresSQL etc.?

Is it worth it to make the switch, if not now when? Which of the open source versions will survive an eventual shake-out?

5) How come no-one bought Sybase?
There are really only three big players left - Oracle, IBM and Microsoft. A few years ago IBM bought Informix leaving Sybase as the outlier? Sybase still has quite a lot of deployments especially in the finance industry. But almost every such company is switching away since Sybase really hasn't had a good regular release schedule for the past few years.

If someone would just come up with a great tool to automate conversion from Sybase-to-XYZ (with minimal hand-coding for extended SPs etc.) they'd make a mint!

6) What will replace the RDBMS?

I don't know about you but there seems to be something in the air, the Object-relational impedance mismatch seems to be hitting a threshold, is the end of the RDBMS in our future (say 20 years?). Will it be the ODBMS? I doubt it.

7) How come everyone talks about coordinating DB transactions - XA and 2PC and the like but I've *never* needed it in practice?
Maybe I just lack experience - but not ever in over a decade have I seen an unequivocal requirement to implement transaction coordination.

8) How come software vendors have such terrible software and no accountability?
I've been working with this JMS implementation for the past year (not IBM, nor Tibco - rhymes with "chronic achoo"). It crashes all the time and can't handle heavy load gracefully! I mean it's a *MESSAGING* server - it's *GOT* to be able to handle a heavy load

9) When will I be able to do more than three things at once with Windows desktop?

Sometimes I click on a URL in Firefox, while waiting to open iTunes and while waiting on that I try to open my email and my whole Windows UI starts to freeze up - the mouse won't even move. OK Unix / Linux aren't very user friendly but the good old ampersand (&) for background tasks does fabulously well in the command line world keeping your interface quite responsive.

Now we're talking just three things at once - relative to the 1980s I've got a frigging supercomputer on my desk - Microsoft come on already! This has been true regardless of how much CPU / memory I have or which Windows version (currently XP Professional).

10) Why is Google apparently trying to buy it's own Spectrum?

See Link #1 or Link#2

Intriguing eh?

And two bonus questions . . .

11) What is the air-speed velocity of an unladen swallow?

"What? I don't know that! Auuuuuuuugh!". The answer is out there - actually it's here.

12) Why do us Programming / Computer Geeks love Monty Python?

Now that's one for the ages!

Java Exception Handling Anti-Patterns

2007-06-12T13:05:00.000-04:00

The following article addresses one of the hardest things for new java programmers to get right - how to handle exceptions - or more accurately the article talks to how *NOT* to handle exceptions.

Link

It was published in 2006 and I'm surprised I haven't seen it before now as it's really quite awesome (I came across it using Del.icio.us)

Anti-patterns they describe include

1) Log and rethrow
2) Throw the plain old generic java.lang.Exception
3) Throwing the Kitchen Sink
4) Catching java.lang.Exception
5) Destructive Wrapping
6) Log and Return Null
(Side note: I firmly believe you should NEVER return null from a method unless you really enjoy debugging NullPointerExceptions or giving them to other people's code - yah I know the Sun spec has several such cases in the core API but still . . . . .)
7) Catch and Ignore
8) Throw from Within Finally
9) Multi-Line Log Messages
10) Unsupported Operation Returning Null
11) Ignoring InterruptedException
12) Relying on getCause()

Two other great Exception handling articles (more from the POV of what to do than what *not* to do) are

a) Patterns for Generation, Handling and Management of Errors by Andy Longshaw and Eoin Woods
b) Best practices in EJB exception handling by Srikanth Shenoy

I particularly liked the Longshaw/Woods ideas of "Log at Distribution Boundaries" and "Split Domain and Technical Errors"

Links to some Good Free Java/J2EE Books

2007-06-08T13:24:00.000-04:00

Most of these are available at The Server Side but I'm very often surprised how few people are aware of these . . . .

There's a number of other free Java/J2EE books out there too but they really didn't pass muster.

I've tried to group them according to how good I felt the quality was - "Fair to middling" means the content probably should be free (or already is free elsewhere) whereas "Great" means it's a really nice little freebie for us developers who spend so many $ each year on tech books.
Some of them are pretty old (circa '00-'02) but still pretty good nonetheless.

FAIR to MIDDLING

Designing Enterprise Applications with J2EE Platform
by Inderjeet Singh, Beth Stearns, Mark Johnson and the Enterprise Team
Link

Designing Web Services with the J2EE 1.4 Platform: JAX-RPC, SOAP, and XML Technologies
by Inderjeet Singh, Sean Brydon, Greg Murray, Vijay Ramachandran, Thierry Violleau, Beth Stearns
Link

GOOD

The J2EE Architect's Handbook
by Derek C Ashmore
Link

Mastering Enterprise JavaBeans 3.0
by Rima Patel Sriganesh, Gerald Brose and Micah Silverman
Link

Jakarta Struts Live
by Rick Hightower
Link

Servlets and JavaServer Pages
by Jayson Falkner and Kevin Jones
Link

GREAT

Swing
by Matthew Robinson and Pavel Vorobiev (1st Edition)
Link (see about half-way down the page)

Bitter Java
by Bruce Tate
Link

Thinking in Java
by Bruce Eckel (3rd Edition)
Link

Core Servlets and JavaServer Pages
by Marty Hall (1st Edition)
Link

More Servlets and JavaServer Pages
by Marty Hall (1st Edition)
Link

p.s. if for any reason any of these links violate any author's rights (I certainly hope they don't) please let me know.

Another fine mess you got me into - Why BDUF should work but . . . .

2007-06-08T08:35:00.000-04:00

I think most people agree that BDUF is fading against the assault of, if not agile methods, then at least iterative ones.

What's the reason? Despite claims to the contrary I do not believe it stems from incomplete, vague or ever-changing requirements although that plays a factor. I think the issue is that frankly, we mere humans (!) are just not smart enough to build complex systems that require so many interacting and moving parts, and to do so in one fell swoop - that is with a Big Design Up Front (BDUF).

(Other factors include the benefits to being first to market even if it's with a lot of bugs! Sadly people's expectations for software are quite low)

Alternatively you could say that the technologies we use are still too complex . . . .

Take for example a sample 3-tier Java/J2EE application - on the Presentation Tier you have

- JSP pages (probably tens to hundreds or more pages each with a myriad links or buttons and inter- and intra-page flows)
- plus associated Javascript
- Now add Ajax (it makes the user's experience better but the work as a whole got harder)
- Struts / Servlets

On the middle tier you have
- Facades / Business Delegates
- Session Beans, Entity Beans, Message Beans
- Probably a great deal more: JMX, logging, multi-threading, JMS messaging, Enterprise Service Buses
- Web Services

On the data tier
- DAOs, ORM mapping (and all that this involves)
- Transactional behavior

This is not to slam Java/J2EE - the same problems must be solved in .Net, Ruby and C# - presentation tier (and it's concerns such as usability, flow, chattiness of requests etc.), middle tier (concerns include scalability, threading, caching, user sessions, fail-over, security etc), data tier (look for data model extensibility, transactions etc.)

Think about it a little more - BDUF worked great in the 60s and 70s where most applications were written with just one language - entirely COBOL, entirely Fortran etc. and it was for a small number of users (tens, hundreds). Now we need to know JSPs, HTML, CSS, Javascript, XML, Java and it's myriad APIs, SQL and DDL and our user-base is the world (millions, billions)!

And we wonder why BDUF doesn't work!?!?! It's like trying to hire someone who can speak 9 world languages fluently and being surprised by a lack of resumes!

Can it be any surprise then that BDUF doesn't work? Due to complexity of the technology space, half the time we're not aware of a problem until we hit it. As a CS geek with a streak of "true" engineer I find this embarassing.

BDUF is not inherently the problem - *WE* are the problem - we're either not smart enough (not sure we can fix that) or we've made the tools too complex and hard to use (we can address this).

We end up having to write code to help solve issues related to things like Cross Site Scripting (XSS) and database table indexes etc. which are so far removed from the actual problem we are trying to solve - building applications for some end-user need.

As Einstein said:

"We can't solve problems by using the same kind of thinking we used when we created them"

In the same way that Java removed the need for us to handle memory management ourselves, we need something (not *just* a language) to solve the "junky" problems - yeah they're fun problems to solve but it's not what our customers, clients or bosses are really paying us for! What's needed is a paradigm shift . . . . 4GLs, MDA etc. all fail because they seek to make abstract or automate what's inherently a very complex space.

As any 6 year old can tell you, automating an error-prone process means you just make more errors in less time!

And as any mathematician would tell you, if you can control the problem space then do so! Why make a problem harder than it needs to be? (Job Security?)

How do we get there? Well if I knew I'd be a millionaire - but I think it has to be a solution which focuses on the data - how it's represented, displayed and persisted - if we can radically simplify that, then we're on our way.

Perhaps even our day-to-day IT language itself - about "data", "code", "interface" is part of the problem - it's all so very Turing/Shannon/Von Neumann - so dry, so linear, so artificial. True paradigm shifts occur when we look outside - FAR outside!

The downside? Probably massive layoffs in the IT industry - the same way mass production and industrialization spelled the death knell for the livelihood of many skilled individual artisans.