dow.ngra.de

ZeroTurnaround is looking for an infrastructure engineer in Tartu (http://bit.ly/zt-infra-eng). If you want to apply or just have a little fun, solve this puzzle:

UEsDBBQAAAAIAIVyUjx/yWgsbQIAAP0CAAAHABwAcHJvYmxlbVVUCQADeTB9S3ow
fUt1eAsAAQToAwAABOgDAAAdUsmumlAA3fcrGtNFX1zABblgXm2jOACXSRBEY9Jc
5knmSb6+vi7OkJyzO+fXnx8T6W4WrB3LbiuOBxXMfNRNW8Wn9NipMa4QbVv8MQVL
05STYRfqADEysKpWFm/3mViqu5EtXlzGPVl6zauMly7vUNt3S9ji1LESwdn63jCN
DZkNHrzCc78lb8/mucZtFFM45ckrs1XnmtOYo34WENfnXkzC9vQ6s3sJEpCifalp
BtvFDjI50bJunpHhegTuhAKuKsh49uGhN9tXPJpkNxknpCaHjgoxivp4MNg4YQSG
V+K8IXs3KvSzK2IcaJOxvWny89ztEn66vIpYcNpw1jnkr7CplWUCGGNneZ0Y3mdK
du/0Ss2S8Zqve2ZQWWQcIsDMh/spoPTCEujcunKTWHZ9JZryK6YlAqi7Z+4noaHM
+SC2KyYws6Vk3gqt4FuqESqyfQ6jSjfkIO0yXJgXr6zUI0L6+CKOcmjZvkFyrmxd
92QoKQ0WHcmRqgiKJ7+I6J0xK8d70ALbNBQh8LMlPLlBefMRVfOVkupsao181s+X
alqrQprbp3QH0CuTxEminYhUtGLm8htNsEVWaVvbzxrTTGTuAqlSEbsXQiMdjSCh
SxWaNYe6hknmS6ND+6g01+aoFnZ/qaURCYTRQBEf9vEp9UmrIxTb7bnzMOFzaFE1
cagV4M+WbexrQrDLPf/eqjROlTqeNYFVbwpYLvV+HTgdbcxavlan9ZhtFp/vb3qb
hYsfE0sHcPXXf0yQeYAV/dbQfxvmfyfYLKIHYKkHYMA7Cd6Ab3i4Cxaf34MB5z+/
Wl/kfZH78fHx+ef3t39QSwECHgMUAAAACACFclI8f8loLG0CAAD9AgAABwAYAAAA
AAABAAAApIEAAAAAcHJvYmxlbVVUBQADeTB9S3V4CwABBOgDAAAE6AMAAFBLBQYA
AAAAAQABAE0AAACuAgAAAAA=

Please don’t post the answer in the comments, but you’re welcome to tell what game is the quote from and how long did it take you to solve it.

Another guest post from our PHB. Obviously he has been reading too much Techcrunch, just discovered icanhascheezburger.com and slacking off during his day job.

This is a story of a start-up built around the nerdiest glasses on earth. If you wonder why and how we’re doing it, how exactly will we make millions of dollars off of it then you’re in luck. We’re planning to document and publish everything on our website and we have just released the first in the series, Converting a pair of glasses into fame and fortune.

Today’s software is so much about integration. You can have a cool Java utility but if you don’t have an Eclipse plugin for that, a large % of Eclipse users won’t adopt (IDEA & NetBeans users require plugins just as much). In the consumer market the same goes for browser extensions and iPhone apps that support the main service with better accessibility.

There are different ways for integration. Usually it is done via an API. The host platform offers some hooks into the system and you can use them to add some custom functionality on top of the host (or maybe just integrate your own product with the host). The result of this in the IDE world is a plugin. JRebel (the product our team is spending the most development time on) has plugins for application servers, frameworks and even IDEs.

If you’re in luck you can achieve everything with the API, if not you need other tricks. If the API does not offer certain public methods or access to some internal fields you can go in with reflection and still use them (of course there are no guarantees if the internals stay the same on version changes).

One step further to the darkside is binary patching. By binary patching I mean adding/changing/removing methods/fields/classes in runtime. This is the approach that we had to take when writing the JRebel NetBeans plugin.

On NetBeans startup we lookup a debugger class and on success try to patch it. In 2009 and using the JVM (not native apps) it is quite an easy task, at least for the most part. No assembler involved (of course you could be using a bytecode generation library), no need to do jumps to correct offsets or even read assembler (or bytecode).

In our case we use the Javassist library. It is a matter of inserting Java code embedded into a String to methods looked up via reflection. For example the following code adds some new code into the beginning of a method.

ctc.getDeclaredMethod("setRequests").insertAfter(
  "org.netbeans.api.debugger.jpda.LineBreakpoint _breakpoint = getBreakpoint();" +
  "java.lang.String _className = _breakpoint.getPreferredClassName();" +
  "if (_className == null) {" +
  "  _className = reader.findCachedClassName(_breakpoint);" +
  "  if (_className == null) {" +
  "    _className = org.netbeans.modules.debugger.jpda.EditorContextBridge.getContext().getClassName (" +
  "      _breakpoint.getURL ()," +
  "      lineNumber);" +
  "    if (_className != null && _className.length() > 0) {" +
  "      reader.storeCachedClassName(_breakpoint, _className);" +
  "    }" +
  "  }" +
  "}"

For the complete source code of the patch see the src folder of the nb-plugin.

In conclusion, the best way to integrate with any system is via the API it provides. If it does not cut it then look into reflection and start using internals. You will lose on maintainability of course. Still not happy? Look into binary patching and have your fingers crossed whenever the target platform releases a new version.

Another guest post from our favorite PHB. I don’t have the slightest idea why he has Eclipse installed or better yet, why is he trying to run it. Probably overheard something from devs at the water-cooler and wants some free time from PowerPoint.

My Eclipse instance starts with a warning popup. Well, most likely it picked up a JRE instead of the usual JDK specified in my environment variables. But hey, I know how to handle property files (ed: seriously?), and they are actually pointing me towards the eclipse.ini.

Clicking the link on the warning popup does not open the file itself though, so I have to manually navigate to the C:\Programs\eclipse folder and find eclipse.ini from there containing:

Adding –vm C:\Program Files\Java\jdk1.6.0_14 to the end of the configuration and restarting. Well – nothing has changed. OK, let’s open up Google.

Proposed solution: -vm option has to be specified before the –vmargs option. Still no help, Eclipse will start with the previously mentioned warning.

Second solution – there has to be a line break between –vm and the value specified – BINGO. We are getting somewhere –

Now let’s just change it to:

And it just works. But for heaven’s sake – why on earth do I have to figure out

• where is the configuration I have to change
• in which order do I have to specify the parameters
• that the key-value options must be separated with the line break

Considering the last warning dialog – why cannot the whole configuration be validated and initialization failed properly? If this were a tool used in-house or only by small number of freaks, then – let it be. But this is Eclipse we are speaking about – there are millions of people working their asses off on a daily bases with this tool. Can’t imagine the time wasted for problems like this …

I haven’t been interested in Agile (or any other methodologies) for a long while. Partially because I found the things that work for me and my team and partially because there was a lot of marketing BS not confirmed by any actual results. This talk promised to deliver some hard data, so I was interested how it goes together with the consulting mumbo-jumbo.

The talk borrows the title and format from the Mythbuster TV show, where experts recreate the urban legend situations to check if they are plausible or not. Scott confirms or busts one myth at a time using the data from the surveys that come from a variety of sources, some of them more trustworthy, some less.

The reasons I couldn’t take some of the conclusions seriously were:
1) Agile is not well defined. There’s a large number of practices considered Agile, and many people will claim that they’re doing agile e.g. if they have a build server.
2) Surveys only tell what people think is happening. If you want to know how long is the nose of the emperor of China you don’t walk around asking people. Worse a lot of those surveys are conducted only among the Agile or TDD community, which gives them a high bias against traditional development.
3) Comparing Agilists to Traditionalists is like comparing Tide to the Usual Washing Powder. There’s no such thing as a traditional methodology, there’s a bunch of them with very different approaches.

Note that here I give only my interpretation of Scotts talk and data, so please don’t treat it as anything else, but my own opinion.

Myth 1: The majority of organizations are now doing Agile.

Survey shows that 76% of organizations claim they are doing Agile.

CONFIRMED!

Myth 2: The majority of project teams are doing Agile.

In the 76% of the organizations claiming to do Agile only 44% of teams report using it. That translates to roughly 33% of the “popular vote” for Agile. Therefore 66% of developers are not even claiming to do Agile..

BUSTED!

Myth 3: Agile is all about development

In the list of Agile practices the only one that is used by more than half of developers claiming to do Agile is Continuous integration (65%). That kind of underlines the fact

PLAUSIBLE?

Myth 4: Agile is just for small teams

A lot of large projects are confirmed succeeding with Agile. In fact success rate isn’t that different from small ones. Would be interesting to see the breakdown of different practices used in small v/s large projects.

BUSTED!

Myth 5: Agile doesn’t work in a regulatory environment

To clarify here are meant environments where errors are critical and thus are regulated by legal or engineering requirements. Surprisingly 33% are using Agile in a regulatory environment. Again a breakdown of practices would be very interesting as there’s bound to be some difference.

BUSTED!

Myth 6: Agile & CMMI don’t work together.

Only 9% reported using Agile. I think Scott put this as BUSTED, but 9% sounds like CONFIRMED to me :)

Myth 7: Agile approaches are “empirical”.

Very weirdly phrased claim. The survey shown was 51% of respondents collecting manual metrics, 19% collecting automatic metrics and the result was CONFIRMED.

Myth 8: Agile teams are mostly building from scratch.

78% of respondents work with legacy at least on some level. Scott had a pretty interesting digression on how Agile practices handle well the legacy code (with tests, refactoring, etc), but don’t give that much attention to the quality of legacy data.

BUSTED!

Myth 9: Agile certification is a good idea.

78% of respondents think certification is meaningless, wonder how many of them are certified (as does Scott). An interesting digression about a guy having both PhD and Scrum master on his business card, as if their value were the same. Certification that doesn’t require any real effort is greatly overvalued in the community.

However although Scott considers the myth busted, I don’t think it makes sense to ask this question from everyone. If this’d be a poll among hiring managers it would make much more sense.

BUSTED?

Myth 10: Agile teams are colocated.

Survey shows that only 42% are colocated.

BUSTED!

Myth 11: Agile doesn’t do up-front estimates.

In the world of budgets this premiss always sounded ridiculous. And unsurprisingly 89% of teams have to provide an up-front estimate (with different level of certainty).

BUSTED!

Myth 12: Agile teams just start coding.

No kickoff is another thing I never believed. From the data about a month of kickoff is usual before starting the actual coding.

BUSTED!

Myth 13: Agilists follow common dev conventions.

Data is a bit confusing, but seems that 59% have some kind of conventions.

PLAUSIBLE?

Myth 14: Rights & responsibilities are part of the agile culture.

The question is quite weird and the data isn’t really connected to it.

PLAUSIBLE?

Myth 15: Agilists test often and test early.

Only 71% in the TDD community are actually doing TDD. WTF? And agile guys are still having integration tests (45%) and hired testers (36%). This confirms my suspicions that unit tests are not the silver bullet as many suppose them to be.

CONFIRMED!

Myth 16: Agilists don’t do up-front requirements modeling.

76% are doing high-level up-front requirement modeling. This correlates with Myth 11, because to provide reliable estimates you need to have an idea what you’re going to be doing.

BUSTED!

Myth 17: Agilists don’t do up-front architecture.

70% do architecture design. This explains the month of kickoff along with the requirement gathering.

BUSTED!

Myth 18: Agilists write some “interim” docs.

Not sure if anyone doubted it, but 56% agree.

CONFIRMED

Myth 19: Agilists don’t do supporting docs.

The numbers are slightly lower than “Traditionalists”.

BUSTED!

Myth 20: Traditionalists write better docs.

Equally bad at writing docs according to polls. I can believe that :)

BUSTED!

Myth 21: More difficult to add members to Agile projects.

Data shows that it’s slightly easier to add in Agile. Promiscuous pairing makes it even easier, so make sure to be promiscuous.

Frankly I heard the other myth that it’s easy to add members to Agile projects, that is busted as well.

BUSTED!

Myth 22: Agile works better than traditional approaches.

The ultimate question :) Success rate over different approaches:

• Iterative — 71%
• Agile — 70%
• Traditional — 66%
• Ad-hoc — 62%

Personally, I think that the variation is pretty small and it’s more important that 30% of projects fail no matter what than the 4% of difference between Agile and “Traditional”.

However when broken down on specific aspects (like cost, time, quality), it seemed that Agile was considerably better. I’d take it with a grain of salt though, as a lot of people take Agile as a religion and measure success accordingly :)

CONFIRMED?