Blog

It’s 3pm. Do you know where you dev team is?

Using data from over 1000 respondents in a still-in-progess (cough, cough) survey about what makes developers tick, we are trying to hack into the core of the developer work week.

Among lots of other information that we unearthed from the depths of the coding den, we wanted to introduce these 3 interesting findings, and get some running commentary from Lincoln Baxter III, Senior Software Engineer at Red Hat (JBoss Forge), founder of OCPsoft, and opensource author / advocate / speaker:

• Finding #1: Devs spend less time writing code than you might think. The median is 15 hours, programmers spend about 3 hours each work day writing code.
• Finding #2: Devs spend more time on non-development activities than you might think. For each coding hour, devs spend nearly 30min in meetings, reporting, writing emails and dealing with timesheets (7 hours to 15 hours)
• Finding #3:  Devs spend more time fighting fires than building solutions

Disclaimer: As with any type of research undertaking, here are a couple of disclaimers: a) This survey is still in progress, and these findings are only preliminary at this point. b) We asked respondents to estimate the time they spend doing activities, so 100% accuracy is not guaranteed. c) Not only developers responded, but also architects, QA folks and system admins, so averages may reflect this too. 

How do Developers spend their work week?

Check out this breakdown of what devs spend their time doing (the top 3 time-consuming activities are marked):

Here are a breakdown of the categories a bit more. We tried to get everything a dev might do during the week, so if you can think of anything we missed, it would be cool to hear about that.

• Writing Code (programming, coding, hacking away)
• Overhead (Building, Deploying, Hardware, Software)
• Communication (Meetings, Chats, Teleconferences, etc)
• Problem-Solving (Debugging, Profiling, Performance Tuning)
• Firefighting (Crashes, Slowdowns, Security, etc)
• QA (Manual & Automatic Testing, Code Reviews)
• Strategy (Architecture, Refactoring, Thinking)
• Process (Bureaucracy, Reporting, Time-keeping, etc)
• Procrastination (slashdot.org, reddit.com,. Twitter, Facebook)

We can see that actually writing code is still the dominant activity of the day, but by no means a majority by itself. There is a distinction between “writing code” and “coding”; “Coding” includes writing code + problem solving, QA, strategy etc.

If we assume a 45-hour work week (9 hours per day, incl. lunch and breaks), developers spend 1/3 of their entire work week producing code.

Is this considered too little, just right or even too much? Let us know what you think in the survey, give your comments below and check out our Extended Interview with Lincoln Baxter III below.

**Next up :: Developer Productivity Report – Part 2: Developer Stress**

Extended Interview with Guest Geek Lincoln Baxter III

ZT: Hey Lincoln, thanks for joining us.

LB3: Glad to be here.

ZT: Can I ask….does it say “The Third” on your passport?

LB3: No, just the Roman Numerals.

ZT: Darn. Anyway, what do you think about Finding #1: Devs spend less time writing code than you think? I mean, according to this, devs spend less than 3 hours each work day writing code?

LB3: To be perfectly honest – and I’m always perfectly honest – I’m not surprised one bit. The biggest drain on productivity is the constant interruptions to our concentration; that can be co-workers, running a build, running tests to check your work, meetings.

It can take up to 25 minutes to regain your focus once you’ve been distracted from your original task#, and if like me, you consider “writing code” to be the task that developers should be focus on, then the size of other pieces in your pie chart begin to make a lot of sense.

Think of a brain as if it were a computer. There is waste every time a computer shifts from one activity to another (called a context switch,) a very expensive operation. But computers are better at this than we are because once the switch is complete they can immediately resume where they left off; we are not so efficient.

When considering context switching, builds and everything else considered “Overhead” are the biggest distractions from writing code. Even though this piece of the pie is only responsible for 4.63 hours of a developer’s week, in reality, the true impact of this problem is much greater.

Once you add in all of the other distractions of the workplace, I’m impressed anyone gets work done at all. Every re-deployment is going to cost you an extra 25 minutes of wasted focus, in addition to the deployment cost itself.

ZT: Alright, on to Finding #2: Devs spend more time on non-development activities than you might think. Based on these numbers, for every 1 hour devs spend writing code, they spend over 30 minutes in meetings, reporting, writing emails and dealing with timesheets (8.25 hours to 14.75 hours). Has it always been like this, or is this something new coming as more IT shops join forces with large enterprise and corporate parents?

LB3: In a desperate attempt to measure and estimate the work that programmers do, we try more and stranger ways to try to gain some kind of understanding. Think about it – in every other type of engineering field, we perform estimates up front, send out quotes, sign a contract, and work follows.

When writing software, however, try as we might, we still have difficulty with this process. Why? Because writing software today has very little to do with engineering.

The cognitive requirements for programming (software engineering) are much more akin to those of composing music, or painting a picture than they are to building a bridge or installing a drainage culvert. The common misconception about us “geeks” is that we are boring, uncreative and dull, but if that’s true then Mozart, Beethoven, and Daft Punk are just as dull.

So why do we insist on measuring software development as if it were an engineering science? We can apply these statistics to bridge building because we have built bridges for thousands of years, and the laws of physics have not changed since then. The laws of computing, however, change daily, and we cannot possibly hope to measure the same way.

This is why the Agile software methodology has had so much success, because unlike when building a bridge, the type and amount of work changes frequently in software development. Agile focuses less on measuring how much work on a task has been completed, but instead how much work remains, and how that relates to how much work can be done during the project timeline.

In fact, at OCPsoft we’re working on a new open-source agile project management called SocialPM, which is being designed specifically for the purpose of creating as few distractions as are necessary, while helping teams stay organized and keep more accurate schedules in an environment prone to change. (You know, to keep managers happy.)

Traditional estimation techniques, they’ve got no hope until we have more standard practices for software development. Let’s give our guys a break eh? Stop with the time-sheets.

ZT: Cool. Ok, so now to our last finding. Finding #3:  Devs spend more time fixing problems than creating solutions. Let’s pretend the non-coding, non-communicating part of the dev day could be split into two parts–Firefighting and Building. Firefighting includes emergencies plus problem solving like debugging and performance tuning. Building includes code reviews and tests, plus strategic planning, daydreaming, refactoring and thinking over architecture.If we break down the work day into parts where devs are spending time actively solving problems or working towards creating solutions, devs spend more time putting out fires.

• Firefighting – Median 7 hours per week
• Building –  Median 6 hours per week

• #1 – Writing a test.
• #2 – Running that test.

We have hugely complex builds that are not properly modularized, and certainly not very testable because how can you test without a database? How can you test without real business logic?If you don’t have automated builds and automated test suites that run in a reasonable amount of time (a few seconds or minutes,) then you are going to spend a good amount of your time running builds and trying to write and run tests; not to mention, you may not see the real issue until you deploy the software to a production environment, because mocks can never hope to replicate a real system.

In terms of Java, we’re seeing new advances in the field of testing – namely a project from JBoss called Arquillian, which allows us to automate the deployment of real tests to a real environment in which all services are available. The fact that you have access to your database, business services, and more is why “Don’t mock me,” is the Arquillian slogan.

If there’s one thing that surprises me about this statistic, it’s that we don’t spend more time fighting fires, because without a good automated build and a solid suite of real tests, we’re going to have problems.

For our readers, customers and fans that didn’t receive this information via email, here is ZeroTurnaround GeekNews for Q4 2011. Feel free to Join the Rebellion.

Quick note: Estonia’s biggest Java conference, GeekOut 2012, has been planned for June 14-15th, and the first speakers to give talked there have been announced. If you have never been to Tallinn and want to see why it’s one of the best cities in Europe, come for a visit!

JRebel News

Over 50 million redeploys prevented…and counting

• JRebel Social 2.0 was released, featuring a new dashboard, social points and more!
• JRebel 4.5.3 was launched, improving JRebel with JBoss 7 and Weld/CDI, plus Hibernate 4
• A JRebel/Liferay Integration project has been activated, and there is even an update since then: You can now reload Liferay JSP Hooks without redeploying!
• JRebel-Gradle beta plugin was released, so now Gradle fans can generate the rebel.xml file needed to enable instant builds 
• Learn how to make instantly visible change with JRebel to multi-module projects in IntelliJ

LiveRebel News

Let Continuous Delivery become your reality

• LiveRebel 1.2 is scheduled for a late-January release, so keep your eyes peeled…
• New features planned for LiveRebel 1.2 will include support for multiple upgrade strategies, including out-of-the-box rolling restarts
• Released a new milestone for the LiveRebel-Jenkins Deploy plugin
• The LiveRebel team doubled in size, so expect a lot more to come soon :-)
• LiveRebel’s current 90-day evaluation period is going to be cut shorter soon, so get your Continuous Deployment itch scratched now!

Stats, Data, Knowledge and Power

The most-read articles and posts of Q4…with a cherry on top

1. Java Productivity Report: India vs. Rest of World
2. JRebel vs. OSGi: Use the right tool for the right job
3. JRebel 101: What JRebel is and how it makes Java development lightning fast
4. Part 1 of the Java Reloading Classes series (5 parts in total)
5. Smelly Communication: How the Suits should assign tasks to Geeks

Cheers to an excellent 2012!

The ZeroTurnaround Team

Java is not dead…in fact, it’s got more than enough energy to kick your app in the butt. Too often, critics focus on niche issues and make unfair comparisons to other technologies or languages that do not have the same level of widespread use, applicability or history as Java. It’s like comparing a car to a carpet.

Children today are able to learn Java. It’s widely adopted among Web and Enterprise App producers. It has seen some amazing improvements in recent years and even more good stuff is on the way. But even excluding those latest additions, Java is still pretty darn cool: consider the widespread applicability and excellent engineering behind the JVM platform, the clarity of syntax, the rich ecosystem of tools and libraries and the fact that Oracle says there are over 9 million Java developers out there (and many billions of app/device users). So why do I hear remarks about Java being “on its way out” or, since back in 2007, that it is becoming “the Cobol of the 21st century”?

The Java platform is an engineer’s dream

First there’s the Java platform. The HotSpot JVM is a marvelous piece of engineering. It does stuff the CLR can only dream of and is so heavily optimized that often Java apps can even match the performance of C programs. Also, there is quite a selection of other virtual machines available (such as JRockit, Zing), should your environment have some specialized requirements.

Secondly there’s a multitude of JVM-based languages, which makes the platform even more amazing. It goes way beyond the famous ones like Groovy, Jython, JavaFX and Scala. Java now includes such treats like invokedynamic opcode and the java.lang.invoke package, making it easier to build dynamic languages for the JVM. There’s already a line up of over 50 JVM-based languages, one of the most interesting ones being php.reboot, which aims to keep the philosophy of PHP but remove its shortcomings. And it also works for Android, too.

Java is mature, but not a language for old people

Java as a language has been the target of much criticism, whining and cursing. I say the language is not dying or Cobol’ish either, quite the contrary. When complaining about Java and recommending better alternatives, people often use strange comparisons. Some people seem to think that Java is still in version 1.4, written in Notepad and requires EJB2 to write a simple guestbook. It is then compared to a high level framework or even a CMS!

As a Java developer, this comparison doesn’t make any sense to me. It is wiser to compare how Java measures up to more intelligently-chosen contestants…How about pure Java vs pure PHP, Python or Ruby? Or comparing the Play! Framework vs Ruby on Rails? Or Spring MVC vs Zend Framework? When put in this light, I feel that Java does not seem like a “language for old people” anymore.

Java is verbose? Of course it is!

People say Java is so verbose, and it slows them down. Critics often refer to the strong static typing and lack of bleeding-edge features in the language. However, I believe this is actually deliberate and a good feature of Java.

Dynamic languages are popular when starting a new small project, but consider this – with the help of modern frameworks and proper tools (i.e. consider using an IDE instead of Notepad), creating a “Hello Guestbook” type of application in Java is a simple, 10-minute affair.

If you want to test that, try Spring Roo and use a stopwatch if needed. Now, let’s take a step outside the trivial CRUD matrix used by cool languages and frameworks in their marketing talk.

Imagine you’re building a system for a mobile carrier and want to allow clients to sign up on their website. You will have to collect a lot of data and possibly invoke various subsystems in the backend. Cool frameworks often break down the minute your program model does not match the user model anymore. For more, I can recommend this wonderful post on that topic by Joel Spolsky.

Java is strong with static typing

Strong static typing has many benefits. I love its simple visual appearance. I can glance at a piece of code and usually figure out immediately what’s going on. It’s like the visual feedback in English – the lgnaugae is so esay to raed taht the lettres can be miexd up isinde wrods, and it’s sitll redaalbe.

Some other benefits of the type system include strong IDE support. Dynamic languages will always be at a disadvantage here. Having a simple, no-nonsense language in a huge project with great IDE and tooling support is priceless. Nothing else comes even close IMHO.

Critics have a point that Java may lack some of the expressiveness when reading a file, transforming xml or iterating through a collection, but you can always create a sub method to handle common cases, or use FileUtils.readLines(). There is also a huge number of libraries available for Java that handle most of the “expressiveness shortcomings” of the language.

Java 7 saw some neat enhancements such as auto-closable resources, String support in switch statements and underscores in numeric literals (I urge you to read up on project Coin). Java 8 promises even more (most interesting part being closures).

The takeaway here is that the language is getting some fresh blood. However, the features will not be some experimental ideas which may or may not be around in two years, but proven and mature concepts. This does not mean the philosophy is mutually exclusive with having fun when programming. It isn’t.

A Fanboy Rests His Case

Is everything about pure Java perfect and justifiable? Of course not. And that is why there is Java 8 in the works. And Java 9. What I personally dislike most about Java is the not-so-smooth core API, and there is a debate whether this has actually more to do with the platform than the language. The core contains the evolution of API design spanning two decades, and modernizing it all will break backwards compatibility. Some parts are too abstract, some not abstract enough. Some bits are too fragmented. Some are just plain weird. Looking at the competition, the core API could do well with the unified communications API like .NET for example. Java 8, with the help of project Jigsaw, may change that.

So there you have it. Pure Java, used properly, is an awesome language. Even more so than Klingon. It will continue to improve and will not go away anytime soon. The effort should not be on replacing pure Java, but using it together with other JVM languages where it makes sense. But for my next Pet Clinic, I’ll stick with Java.

***

P.S… An Example of Java in Use

This article, like Java, is a bit verbose, so I’ll leave this example for any readers who want to continue.

Say you need to build a web application and you need control over the html output or http requests. Consider the stack of pure Java, Spring MVC and Hibernate. Yes, it’s an old combination, almost like a cliche, but it works beautifully. It has many benefits and little downsides, most of which can be eliminated with a little help from your tools.

Writing Java code is fast when using a modern IDE (Eclipse, Netbeans, IntelliJ). All of them have code completion and shortcuts that take much verbosity-related angst out of your day. Using relatively modern (i.e. less than 3 years old), versions of Spring and Hibernate, you don’t need to write five miles of xml to have red buttons with rounded corners (it has never been that bad but people love exaggerating). You can use annotations most of the time. Even when you need applicationContext.xml, using a Spring IDE plugin makes that a breeze. With JEE 6, you don’t even need a web.xml. Even if you have to use an older servlet spec, IDE will generate web.xml for you. It can generate a project layout and add servlets just like Grails’s command line console, but better.

The last bit you might complain about is the turnaround. Making a small change and seeing the result has always been fast in PHP, but not so much in Java. Again, tools are there to help you. Without tooting our own horn, JRebel, for example, will instantly reload classes in the running application regardless of your stack. Same goes for refreshing Spring and Hibernate configuration. It goes even further by mapping resources between the workspace and the deployed application. This makes your life easier when working with static resources too – you don’t need to copy jsp’s to the right place or run any build script to see the changes. Just press ctrl-s.

You get to keep all that’s good about Java. In short – you’ll have the best of both worlds.

Tweet

Just as the roads were starting to freeze over in Estonia, the tiny, northern-European country that keeps popping up on the global innovation radar, 25 tech experts met to discuss the upcoming year.

This group, which included investors, CEOs, engineers, advisors and journalists, put together a lineup of the most influential thought leaders and IT companies in Estonia to watch in 2012. Having won three awards in 2011 alone and attracting the attention of Bain Capital Ventures in the USA, ZeroTurnaround was selected as the #1 Estonian IT company to watch in 2012.

IT experts voted ZeroTurnaround #1 company to watch in 2012Sten Tamkivi, Director of Product Focus and Catalogue Operations and General Manager of Skype in Estonia and Advisor to the President of Estonia said (translated from Estonian), “We will see in 2012, how smoothly gears change from [Webmedia to Bain Capital Ventures]. Looking from inside, I like the joyful geek-culture that can be seen beyond the borders of ZeroTurnaround; a team with 50-100 people is just about the size where soft values and unique culture helps the company go further and not break down.”

Undoubtably, 2011 was “the year of JRebel”, winning the Duke’s Choice/Oracle Innovation Award, JAX Innovation Award and Estonian Innovator of the Year Award all in 2011. A visit from the President of Estonia to the company’s offices confirmed ZeroTurnaround’s position as a major innovator in the field of Estonian IT.

In 2012, ZeroTurnaround will focus on introducing LiveRebel to operations teams all over the world, in an attempt to help companies see their Continuous Deployment/Continuous Delivery goals come to fruition.

This year will also see the company investigating what makes developers tick. ZeroTurnaround recently launched a survey to get at the heart of how coders spend their time at work, plus which tools, technologies and employment conditions increase or decrease productivity, stress and work satisfaction.

**Teaser: The average developer spends less time writing code each week than one might think. The survey can be found here: http://0t.ee/prosurvx12

According to Taavi Kotka, Managing Director of Webmedia Group, Estonia, it is difficult to call ZeroTurnaround a ‘startup’ anymore, but a company that needs to follow an aggressive vision and product goals. “If the ZeroTurnaround team will manage to do this, they will be Estonia’s highest valued software company by the end of 2014.”

Estonia is pushing hard on to become world-leaders in IT innovation, setting up programs (like e-Estonia, a pet project of the country’s president) that make it easier for people to create their own startup. ZeroTurnaround is proud and honored with it’s recognition as the “#1 Company to Watch in Estonia in 2012”.

Tweet

Tweet

If you’ve ever worked in a large team before, then you know that even figuring out where to go for lunch can be a pain. So you can imagine that a large team using JRebel can find it difficult to track and manage overall team usage, see the number of redeploys prevented, how much time has been saved, and so on.

For just these cases, we developed the JRebel License Server, which provides an easy way for companies to manage their multiple enterprise license subscriptions. The JRebel License Server is standalone application written in Java, just like JRebel and LiveRebel, which makes it platform-independent. Using scripts provided with the license server, you can quite easily run the server as a service in Linux; however, running this service in Windows needs an additional software and configuration.

This article will show you how to run the JRebel License Server as a Windows service using a well-known application named Java Service Wrapper from Tanuki Software. Although the configuration process is well described in the product’s documentation, let’s see how Java Service Wrapper can be integrated into the JRebel License Server.

STEP 1. Obtain software

Download the ZIP package of Java Service Wrapper from the Tanuki Software site here: http://wrapper.tanukisoftware.com/doc/english/download.jsp and unzip the archive to your desired location.

Next, download the ZIP package with JRebel License Server available from ZeroTurnaround.com: http://zeroturnaround.com/jrebel/license-server/ and unzip the archive to your desired location.

STEP 2. Put the Pieces Together

The Java Service Wrapper application is able to integrate with applications in four different ways, which are described in the documentation at http://wrapper.tanukisoftware.com/doc/english/integrate.html. We choose the fourth method, because the JRebel License Server is configured to run as an executable jar.

Note: There are four directories that are required to be configured in order to be able to use the Wrapper.

1. bin directory

First, please copy the following files from Java Service Wrapper directory into JRebel License Server bin directory:

{WRAPPER_HOME}\bin\wrapper.exe
{WRAPPER_HOME}\src\bin\App.bat.in
{WRAPPER_HOME}\src\bin\InstallApp-NT.bat.in
{WRAPPER_HOME}\src\bin\UninstallApp-NT.bat.in

Rename the three batch files to ZTLicenseServer.bat, InstallZTLicenseServer.bat, UninstallZTLicenseServer.bat.

You should now have:

2. lib directory

Copy the following two files into the JRebel License Server lib directory:

{WRAPPER_HOME}\lib\wrapper.dll
{WRAPPER_HOME}\lib\wrapper.jar

You should now have:

3. conf directory

Copy the following template file wrapper.conf.in into the conf directory of JRebel License Server and rename it to wrapper.conf

{WRAPPER_HOME}\src\conf\wrapper.conf.in

Obtain your Java Service Wrapper license and put the license code into wrapper-license.conf in the conf directory of JRebel License Server (Hint: you need to register on Tanuki Software site to obtain a trial license).

You should now have:

4. logs directory

Create a logs directory in JRebel License Server folder.

STEP 3. Configuring Java Service Wrapper

Open the wrapper.conf file in an editor and make the following changes below. A detailed description of the configuration steps can be found at http://wrapper.tanukisoftware.com/doc/english/integrate-jar-win.html#wrapperconf, but we will change this file in six places:

1. Add wrapper.java.classpath.2=../lib/zt-license-server.jar after wrapper.java.classpath.1=../lib/wrapper.jar line.
2. Replace <YourMainClass> text with com.zeroturnaround.jrebel.WebServer.
3. Replace @app.long.name@ text with ZeroTurnaround License Server.
4. Replace @app.name@ text with ztlicenseserver.
5. Replace @app.long.name@ text with ZeroTurnaround License Server.
6. Replace @app.description@ text with ZeroTurnaround License Server.

Putting it all together, we get the following:

wrapper.java.classpath.2=../lib/zt-license-server.jar
wrapper.app.parameter.1=com.zeroturnaround.jrebel.WebServer
wrapper.console.title=ZeroTurnaround License Server
wrapper.name=ztlicenseserver
wrapper.displayname=ZeroTurnaround License Server
wrapper.description=ZeroTurnaround License Server

STEP 4. Running JRebel License Server

Your shiny new JRebel License Server now can be run by executing the batch file bin\ZTLicenseServer.bat. Please try to execute the server at least once as a console application to verify the configuration before installing it as a service. If the server is working OK as a console application, you can stop it by pressing Ctrl-C and install it as Windows service by executing bin\InstallZTLicenseServer-NT.bat.

After successfully installing ZeroTurnaround License Server service will appear in the list of Windows services and you can start it like usual Windows service:

That’s it! Your license server is now running as service.

STEP 5: Let us know if it worked!

Please help us, and others, with your feedback. Just post your comments and suggestions to our forum, or below in the comments section.

Just a month has passed since the last minor release of JRebel and we’re now happy to announce the very first release of the year 2012! In this minor release we’ve added some more cool features and improved some of the existing ones. The changelog is available for the impatient, but let me to highlight some of the important updates:

We’ve added WebLogic 12c to our test suite and JRebel 4.5.4 comes with the initial support for the brand new version of the application server. The support for web fragments was improved as we’ve noticed that some of our users demand that. The existing Liferay integration have been improved to handle Liferay XML configurations. A critical bug of super class annotations not being handled correctly has also been fixed.

JRebel is heading towards 4.6 release now – be prepared for more awesome stuff!

Tweet

Happy New Year! Coming directly from the field of Java development, this article consolidates a collection of technical reviews, how-tos and love letters about JRebel from 2011. 

JRebel + Liferay

“Simply put, [JRebel] is a MUST HAVE for Liferay portlet developers. I’m hooked! Over the past 6 years of portlet development, this product could have saved me COUNTLESS hours of development time waiting for redeploys.”

Neil Griffin’s summer blog post about eliminating redeploys during Liferay portlet development was a great introduction to using JRebel and Liferay together. In November 2011, after having a few months to play around with JRebel, Jan Gregor contributed a post of his own, asking developers to really think about how much time they forfeit each time they redeploy their app. There is now an active JRebel-Liferay integration project due partly to the efforts of Neil and Jan, and we’re happy to say that since Jan’s post, there has been an update: JRebel now supports changes to Liferay JSP Hooks without redeploying (read more).

JRebel + Groovy, Grails and Gradle

“Auto reloading in Grails 1.3.x sucks a lot…but in the meantime I found a better auto reloading solution that works for me in the 1.3.x series…JRebel is a tool that can autoreload classes in a jvm when it detects a .class file has changed.”

No one has said that there is not a secret JRebel-Groovy roadmap located 200 meters below the earth’s surface, but that’s all the information we can give ;-) We’ve been putting some time into looking at how JRebel can add more time-savings to development using tools like Groovy, Grails, Gradle and other G-tools. Coder Aaron Babcock gives a succinct overview of solving his issue with auto-reloading in Grails 1.3 using JRebel, and found solace with a better auto-reloading solution. Chris Mayer at JAXenter introduces “Groovy Fraternity” folks to JRebel in a write-up of our JRebel-Gradle plugin release as well.

JRebel + Glassfish

“I use JRebel to speed up my development. It is a really impressive tool allowing to develop full blended Java EE application as you would develop in PHP.”

Cedric Gatay wrote a short how-to for using JRebel with Glassfish to instantly reload ejb-client and letting others know how to generate rebel.xml for a Maven project. The ZeroTurnaround team really enjoys to see these articles, as it always provides good insight as to how users are implementing JRebel in their own projects. Thanks Cedric!

Using JRebel with web fragments

“Our team recently added JRebel to our toolbox, and we love it. We use Tomcat in our day-to-day development and getting rid of the annoying reboot to see the changes in code and resources was a big relief.” 

In Anna Gos’ blog post, her team implemented JRebel on their new Tomcat project, which uses web fragments, a Servlet 3.0 feature. This post is a short orientation for configuring JRebel in a maven project structure to instantly reload classes both in the main web app as well as the web fragment. Thanks for your great post, Anna, and keep up the good work!

JRebel Rocks, JRebel time-savings [sic]

 “I can only say: “Once you go JRebel you never want to go back without it!”

So says Balder Van Camp, a freelance coder from Brussels who has worked on projects at iText and several anonymous Belgian juggernaut firms. After his intense praise of JRebel while developing a large web application, we later met Balder at Devoxx 2011…nearly as intense as his blog posts would suggest, Balder enjoyed some cold beers with the ZeroTurnaround team. His posts are not technical walk-throughs, but an overview of JRebel’s benefits, including his views on not only the real time lost to continuously redeploying your Java app all day, but the opportunity cost that each interruption has on attention span and returning to the code. Thanks Balder, and good luck!

We send our best wishes for the new year to all JRebel customers, users and free license recipients. If you love the product, and want to see, hear and read more, check out our “Join the Rebellion Tour” page to see where we will be in 2012! http://tour.zeroturnaround.com (Rest of World locations coming soon!)

Tweet

Does something smell around here?

Not unlike the great zebras and lions of the wild, the “Suits” (Marketing, Sales, Creative) and “Geeks” (Dev, Ops, Infra) in an IT company often face misunderstandings. When highly-technical and less-technical employees in a fast-growing tech shop like ZeroTurnaround need to accomplish something jointly, good communication is clearly necessary, but it’s not a one-sided thing.

There is a symbiotic relationship at play; the Suits are at least partly responsible for propagating the Geeks’ natural habitat so that we can all work together in peace and take home a salary. The Geeks make the product and tell the Suits why it’s good. The Suits then turn this into revenue and we all have jobs. Yay!

So how does it work in a distributed work environment, where most direct communication occurs over Skype? In a company where people are working in different offices in different continents, communication becomes naturally less efficient. While technology has been responsible for making a successful distributed work environment possible, I’m continually noticing that, like anti-virus software, solutions to communication struggles are always a few steps behind the next emerging challenges.

Examples of smelly communication (unpleasant for everyone)

My tree isn’t the way I want it either…

Example 1: Infrastructure Smell

To: Infra Geek
From: Salesbot
Subject: $h*t!
Message: Oh crap. The promo codes aren’t working. Please fix ASAP!

To: Salesbot
From: Infra Geek
Subject: $h*t!
Reply: Please send URL

The Salesbot is like, WHAT? What freakin’ URL is he talking about? Go try to use a promo code and see if it works! But from his perspective, the Infra Geek has been given no valid information that would allow him to proceed. Infra Geek is the deity in his own realm, where things follow the rules he has made. Salesbot’s bug fix request is an obvious foreigner in Infra Geek’s little world, and it’s come wearing socks and sandals.

Example 2: Branding Smell

To: Java Warrior
From: Marketing Droid
Subject: Product name?
Message: Hey, your blog post about our new plugin doesn’t include the product name at all. Could you please add it in there and include URLs?

To: Marketing Droid
From: Java Warrior
Subject: Product name?
Message: What kind of URLs? Don’t enough people already know about us?

I think it can be considered a rule of thumb these days that providing highly searchable channels for content distribution to all the little nooks and crannies of the interwebs is pretty important. It can be difficult to get Geeks to see Marketing’s perspective on the importance of using particular language (or, “marketing speak”) to enhance the impact of a blog post or product release announcement.

Example 3: Getting Data Smell

To: Operations Wizard
From: Marketing Droid
Subject: No emails!
Message: Um, this page is giving out free licenses of our software and not collecting any details about the people interested in our product. We need to get their names and email addresses, please implement!

To: Marketing Droid
From: Operations Wizard
Subject: No emails!
Message: Why do you want their email addresses? Letting people know about cool products that save them time and money is spam. I’d prefer if we never spoke to anyone who comes to our website. Many thanks.

Ok, so maybe this last one is a bit exaggerated, but the essence is there. Geeks prefer to employ bizarre methods to get random trolls to somehow find out about our product (which, in their opinion, should also be completely free). Marketing (and with that, some ads and salesbots) is a “necessary evil” to certain people, but if your products are awesome and helpful to tens of thousands of Java developers, you shouldn’t worry about telling people about them. After all, if no one ever found out about Angry Birds, how would you spend your time at the airport now?

Is there anything to be done?

Geeks prefer maximum efficiency in most things, which means that they will often ignore something presented ineffectively in their eyes, ironically concluding with business guys thinking that they don’t get stuff done. What we’re dealing with here is a fundamental gap in understanding between translating the language of business needs into the language of technical requirements. Here are three very simple ideas that have helped the ZeroTurnaround team…

1. Treat your colleagues like your customers

Good marketing droids should be able reach any audience with the appropriate language, tone, form etc. They are paid to do this, right? Why should it be any different in the office?

Here is what technical information a Geek really needs to know–and should be provided:

• Which exact feature is not working?
• What is happening now, and what is the expected outcome?
• Where is a detailed test case that I can replicate on my own side to confirm the malfunction?
• And quite possibly: When will marketing people learn to properly describe a technical problem?

Sadly, many Marketing guys honestly cannot believe that any more information than “Not working here!” is needed. But there will be the realization that although Tech folks and Marketing folks both breathe air and [often] speak the same language, mutual comprehension is by no means guaranteed. Using tools like FogBugz or Trac for task management is a huge help.

2. Don’t be afraid to pick up the phone

Regardless of how much time is spent communicating via Tweets, Posts and otherwise mass-audience directed blasts, remember that it is probably quicker just to pick up the phone. Free videochatting has been gloriously free for years (even though we still complain about the quality!) It’s easy to wait around for an email reply, but the deluge of non-voice communication eventually bottlenecks.

3. Invest in face time every so often

What I’ve found to work especially well is direct face-time (and not on a Mac). Spending time with someone you work with every day virtually but may have never met in the real world can do a lot, and cut down on task completion by hours, if not days.

For managers, this might mean flying your people around so that they can work at the same desk, then get slightly intoxicated together and possibly fight off some criminals wearing masks. You’ll find that a couple of black eyes does a lot for rapport between two teams of different POVs. I’d like to say “Budgetary Considerations Be Darned!”, but that’s not really the way of it. Do your best, and try to see the hidden social benefits as a great excuse for an actual ROI.

TL;DR – The “Suits” (Marketing, Sales, Creative folks) and The “Geeks” (Devs, Ops and Infra folks) of an organization need to plan a communication strategy that includes smart writing, good task description, more face time and the willingness to understand each others’ POV to be successful working  in geographically distributed offices.

During the season of holidays, even the code-geeks lift their heads from the computer and ask themselves: what is it that I am doing and why am I doing it? At ZeroTurnaround, the answers came quickly when we had a all-hands-aboard team meeting in Estonia last week.

The answers were quick to come (hey, we need to get back to our code, not fool around and do nothing!), such as that ZeroTurnaround has a product that actually gives value and is needed by our customers (have you heard of JRebel?), that our team consists of intelligent people who take responsibility for their work, and on top of that we can still have tequila shots at work parties. There was something else that still is ringing in my head like a Christmas Carol, which is what Oleg from the LiveRebel team said: “When I look at Lauri’s or Rein’s written code, I think to myself that it’s a work of art!” All in all: We make art with passion in our office.

We hope that our passion for making Java fast and fun helps you write gorgeous code, and inspires you to turn your work into an piece of art. Have a wonderful holidays and a great New Year!

Older Entries »