Ouch. I’m sure most of the Java developers I know would cringe at the headline to this post. Inflammatory or not, I think this is the crux of trying to entice this clever, often commerce-averse brood. There is often a huge cultural chasm between heads of marketing departments (who, let’s face it, as marketing operations guys we’re always trying to impress) and your average enterprise Java developer (who is often tasked with evaluating different vendors).
This was definitely my takeaway from a recent session on this topic at the TechTarget Online ROI Summit. Peter Varhol, Editor in Chief, TheServerSide.com and Brian McGovern, Publisher, Application Development Media, TechTarget led the discussion, however there was also significant input from Eugene Ciurana, Director of Systems Infrastructure for Leapfrog Enterprises.
TheServerSide is one of the top resources for Java developers. They have recently conducted a survey of their user base which throws up some interesting stats on the state of enterprise Java development.
How much experience do they have?
70% have more than 5 years,
22% have between 3-5 years.
Where do they fit in within the organizational structure?
50% are part of central IT organization.
In what kinds of companies can they be found?
No surprise that most work in the technology and finance industries. 75% can be found in SMEs.
What are they working on?
75% are building mission-critical applications,
80% work on web applications,
only 8% are currently working in mobile.
Pains of Java development
From here on, the discussion moved in a qualitative direction.
Some issues around architecture/frameworks:
- Too many to evaluate – there is a problem keeping up with all the new technologies
- Open source projects will be considered but are of varying continuity (eg. a problem to know whether the framework will be supported long-term)
- What framework do you choose?
- Performance and scalability – how well does it scale?
- Developers dislike vendor lock-in – they like to have the idea that they do have choice if something goes wrong (one advantage of open source)
Day to day issues
Some big problems Java developers face:
- Can’t find/fix a bug (especially damaging if the bug is in the framework)
- Build breaks kill hours of development time, and are compounded if outsourcing means teams are split across geos/time zones
Why should we care about these? Read on…
Enterprise software site requirements
Developers are looking for features that solve problems, and take away their pain points. Addressing these when positioning products is key. State the benefits upfront, eg. ‘fix bugs 50% faster’.
In order to reduce potential risk, developers are also looking to get their hands on evaluation copies of software – this is the best way you can sell to this audience (from an anecdotal point of view, I know we see campaigns run better if we offer demos/evals). The takeaway here:’try before you buy’ is essential, and this needs to be the full version – no ‘crippleware’ (eg. with print/save disabled).
The Open Source Challenge
Developers look first for open source as these generally have the latest and most innovative technology. However questions around open source relate to the quality of the support and the longevity of the product. Having said that, it is felt that support is generally better on open source platforms as there is often a large developer community base ready to answer questions and address bug fixes.
Enterprise software websites should borrow from the best of the open source model: engage the development community and offer strong online support options – a forum needs to be visible. Also, ensure experts are out in front of the customer. As much information as possible should be public so answers can be found quickly on Google.
Remember that potential customers will be looking for validation before purchase: references are gold.
At this point, the marketers in the room asked what kind of vendor content works well? These are some of the answers that came back:
- Source code can be interesting (as well as useful)
- Webcasts generally take too much time and are often avoided
- The same goes for other video – unless it’s interviews with interesting people, but all video should be short (eg. create something for the 5 minute downtime when a developer is waiting for code to compile)
Big documents work well: explain the product in detail and how exactly it will help a developer
How do developers learn about new technologies? The omnipresent Google came up here. Choice quote: ‘I want to talk to the guy that wrote this’.
All in all, I found this session one of the most revealing on the subject of creating appealing content for the developer crowd. I’ve found myself wincing on occasion whilst writing this with the frequent mention of ‘developers’, as if they are a homogenous group. In today’s complex workplace, that is probably a vast oversimplification. However, having said that I did come away with the feeling that this group of eventual end users have demands at the evaluation stage that we as marketers often fail to meet. At the end of the session, it was asked whether the developers present could give any good examples of enterprise level software websites they could recommend. Perhaps Sun? What about Oracle?
They drew a blank.