A New IDE(A), Overcoming The Comfort Zone Hurdle

I recently started a new assignment, where the predominant IDE in use is IntelliJ IDEA. Now, I am quite an Eclipse user having exploited its open source powers for the most part of my career. There are many reasons for this, the most obvious one being that is has been the de facto IDE for most projects I’ve been involved in. There have been a few occasions where I had the chance to try out, or switch to another IDE but I’ve never been forced to do it. And that’s why I’ve always gone back to Eclipse. The problem is that you get used to your IDE. It IS the main tool we developers use in our daily struggles to bring fluffy features into working software… You don’t want to start looking for a type hierarchy for five minutes, or an extract method refactor for another three, in the middle of your zen coding flow. I am one of those that try to learn and use as many of the available keyboard shortcuts as possible. First, it helps avoid hand and arm strain if I can avoid using the mouse, and second it minimizes the delay between having an idea and producing code. If I have to go looking in menus, or lift my hand for a split second, I percieve it as a mini-impediment in my thought process.

So, back to my new assignment, and IDEA. This time, the use of IDE was more of a requirement. I could still use Eclipse if I wanted to but I thought that this time I’d give it a real shot. At first, I tried using the Eclipse keyboard mapping available in IDEA, but I found it lacking some of my key (pun!) bindings. Instead I opted for the default bindings, used a keyboard chart on a separate screen and every time I got stuck fumbling at Ctrl-O or something similar, I made time for finding the exact equivalent. To my surprise, this learning process didn’t take too long, now that I had allowed myself to stop and really look things up.

I’m not going through a complete comparison of the two IDEs, but here a few initial observations. The IDEA Maven features are very neat, and is great for our profile-based build settings. Subversion seems to be a little bit lacking though, and I’d prefer Eclipse on that point. IDEA makes much more use of colors and markers (by default), which is actually a bad thing since I have impaired color vision. The Eclipse formatter seems to work more like I want it to, while the IDEA one doesn’t interfer as much with your line breaks. Eclipse templates such as “foreach” work better. Finally, you don’t really save things in IDEA as you might do in Eclipse, things are automagically saved and built.

Below is a short list of my most commonly used bindings, and the rough equivalents in both IDEs:

IDEA Eclipse Functionality
Ctrl-G Ctrl-L Go to line
Alt-Enter Ctrl-1 Quick Fix
Ctrl-Shift-Backspace Ctrl-Q Go to last edit
Ctrl-Q F2 Show javadoc
Ctrl-Alt-B (Ctrl-T->choose) Go to implementation. Not sure about the Eclipse one here, but I usually open type hierarchy and choose implementation
Ctrl-B F3 Go to interface/implementation
Ctrl-Space Ctrl-Space Note that you must use Ctrl-P (in IDEA) to see parameters of a method call you are making, e.g. method.(/*what args exist?*/)
Ctrl-N Ctrl-T Open type
Ctrl-Shift-N Ctrl-Shift-R Open resource
Ctrl-Y Ctrl-D Delete row
Ctrl-F4 Ctrl-W Close tab
Ctrl-H F4/Ctrl-T Type hierarchy (tabbed vs inlined)
Ctrl-F12 Ctrl-O Method list (prefer the Eclipse one)

From Ad Hoc To Agile @ Avega Elevate (2011)

So, yesterday we had an Elevate at Avega, where we discussed moving organizations from using ad hoc processes to Agile ones, using the fishbowl format. We were fortunate enough to have Håkan Forss with us, who contributed greatly! Thanks for coming down from Stockholm J

Although, the fishbowl format doesn’t necessarily produce amazingly quantitative results, it is excellent as a form of sharing knowledge and thoughts. The value of this kind of discussion is still great, and for me just raising the question and having a bunch of experienced consultants looking at it, is very important.

I think we concretized a few things though. We talked about what Agile methods can bring to the table for any organization or project. We talked about what impediments exist in ad hoc organizations that must be managed when trying to reform. Finally, we talked more in depth of how to actually accomplish this.

We agreed that Agile methods have a greater chance of avoiding building products or product features that no one uses (the 45% unused rule). Agile can give individuals and teams more freedom to act, giving a morale boost and possibly knowledge and responsibility expansion. One of the biggest impediments is an organizational lack of faith in Agile methods, i.e. there is a problem in providing method creditability to managers and teams. Does the new method really work? Do we benefit? Where are the results? Old organizational hierarchies and practices also exist; we fear what we don’t know and even though we logically could see a new method being superior, we cling on to the old ways. Certain people have strongly cemented roles, and can have a high resistance towards change.

Finally, we talked a lot about the merit in moving toward an Agile approach with an iterative mindset. Using an Agile change backlog and introducing small experiments such as letting the DBA help the developers to write scripts during one sprint and then evaluate the results, are examples of such an approach. You cannot create a cookbook recipe however, and you must look at the organization, its needs and its goals to be able to choose the right Agile method and way of reforming.

This was just a brief summary; there were many other good ideas and conclusions. The only way not to miss out is to come and join us! Next time, we will learn how to benefit from social media, invite yourself here: [http://avegagroup.se/synsduintefinnsduinte] (that was 2011, this is a re-post).

Agile Issues In Öresund

There is one thing that has started to make me just a little bit uneasy about Agile and Scrum. It’s an issue that has come up in different projects, time and time again, and while I am an avid Agile proponent it makes me frown and even fume a bit on occasion.

It’s about how Agile teams perform and the correlation to the way people and organizations are transferred from working with a waterfall, ad hoc or other development process to Agile in general and Scrum in particular. In my experience, this metamorphosis is often not done in an adequate fashion and sets up the whole organization for confusion and nasty problems later on.

Sometimes the management gives a green light to start the transformation, but doesn’t bother to learn what is required of it and lays the responsibility on the development organization. Sometimes the new Scrum Masters are old project managers, molded into a new role and forced to think in a way that is quite different from their previous experience of PMI and the like. Sometimes the new Scrum Masters are skilled senior developers, brilliant architects, or simply unmotivated developers or test managers that have no other place in the project. Yes, that last one is more common than anyone wants to admit. On occasion, someone gets the honorable Scrum Master hat but agrees to also fulfill his other one or two full-time roles… A few times I’ve worked with developers that had such little training in Scrum that they didn’t know how to behave in the daily standup, or how and why to unit test, nor how to…. you get the idea.

Actually, none of the above are rare incidents. In my geographical region of work, they are instead commonplace and not exceptions. My question is simply: Can a person really go from knowing little about Agile to being proficient enough for it to work, in the twinkle of an eye, or say… two days’ worth of simple training? Of course they can’t, I just like using rhetorical questions!

Flaccid Scrum

Martin Fowler and Ken Schwaber have both acknowledged these issues that Agile is struggling with.

Fowler writes in his blog (http://martinfowler.com/bliki/FlaccidScrum.html) that although teams adopt the processes and practices of Scrum, Scrum doesn’t mandate any particular technical practices. After a few iterations, the code starts to hurt internally due to lack of technical attention. However, he also points out that many teams fail because the team itself fails, and most likely would have failed regardless of development process. I agree with this, but it certainly doesn’t help that many teams aren’t even getting the Agile processes right…

Schwaber mentions flaccid scrum in his letter (http://www.scrum.org/originsofscrumorg/) on the inception of his new Scrum organization http://www.scrum.org. He singles out the need of better and more thorough education of all participants of Scrum via new course assessments and better instructors. Of course, according to Schwaber, he wasn’t allowed to do this at http://www.scrumalliance.org, and promptly started the new organization. Regardless of the intentions of each party I’m happy to see some competition in the field of educating Scrum recruits.

I believe that further improvements could be made if managers improved in their “Agile management” role. They can’t just drop Scrum onto the development team and hope for the best while old office divisions, roles and processes remain. An even bigger responsibility falls on the Scrum Masters and Product Owners. The collaboration between these and the team are almost always lacking in some regard; communication often being the aspect that isn’t working as well as Agile wants it too! In any case, this is a pressing matter that I would very much like to see improve quickly, before Agile gets the didn’t-work-stamp.

I’m very interested in hearing what the situation is in other geographical regions, and also what remedies or cures of these symptoms exist, be it an iterative introduction of Agile or perhaps a  Kanban approach. Feel free to share your thoughts below.

Finally, I am very pleased that my suggestion to bring the topic to my company’s public live forum was accepted. So, if you’re in the area of southern Sweden, you are more than welcome to join us in a heated fishbowl (http://en.wikipedia.org/wiki/Fishbowl_(conversation)) discussion http://avegagroup.se/Franadhoctillagilitet on 11/16 (that was 2011, this is a re-post)!