Summary of the Schneide Dev Brunch at 2012-10-14

Two weeks ago, we held another Schneide Dev Brunch. The Dev Brunch is a regular brunch on a sunday, only that all attendees want to talk about software development and various other topics. If you bring a software-related topic along with your food, everyone has something to share. The brunch was so well attended that we had trouble to all find a chair and fit at the table. We had to stay inside as the weather was rainy and too cold for prolonged outdoor sessions. Let’s have a look at the main topics we discussed:

Work hard, play hard

The first topic was a summary of the contents of the documentary movie “work hard play hard” about our modern work places. The documentary is a recommended watch for everyone thinking about joining this side of the industry. It’s beautiful sometimes and very painful to watch most times. You might cherish some of the rougher edges on your workplace afterwards. The DVD is out now.

Dual Monitoring

A short discussion about the efficiency increase that happens just by adding another monitor to your desk. There was no dispute: If you don’t at least try it, you waste money. That’s what I meant when I blogged about the second monitor being an profitable investment. Just one downfall, it shouldn’t end like this.

Management by Directive

Another discussion about the management of large departments. The “directive issuer” manager style is a common sight in this environment. I won’t repeat the discussion itself, but rather add an amusing story about an ex-military commander running a software development company. Enjoy!

Review of the Sneak Preview “Quality Assurance Best Practices in Karlsruhe”

There was a “sneak preview” organised by the VKSI, a local association of software engineers a few weeks ago. The topic of the whole event was “Quality Assurance Best Practices in Karlsruhe“. The event was divided into three independent presentations with different topics:

  • Non-Functional Software Tests” by Gebhard Ebeling: The talk was about realistic load- and performance testing of complex applications (and websites). While the presentation omitted tools and code completely, there were some take-aways even for developers that had never performed these types of tests before. This was arguably the best presentation of the event.
  • Contracts im Software Engineering” by Ben Romberg and Stefan Schürle: This talk was about the benefits of software contracts (think about checked method or class invariants) and the presentation of a particular implementation in Java, namely C4J. The perceived problem with this solution was the rather clumsy source code necessary to define the contracts.
  • MoDisco Software Modernization & Analysis” by Benjamin Klatt: MoDisco builds a model out of source code that is detailled enough to apply meaningful transformations to it and have the exact same source code (plus transformed code) as output. The idea looked very promising, but the presentation lacked actual source code examples. Nonetheless, MoDisco proves that there is a future for modell-driven analysis.

We had a lengthy discussion about software contracts and Design By Contract (DBC) in general. One tool that got mentioned several times was “CoFoJa” from (at least initially) Google.

Book review: Java Application Architecture: Modularity Patterns with Examples Using OSGI

In the rather new book of the Robert C. Martin signature series, Kirk Knoernschild tackles the hard task to teach software architecture through a book. One participant read the book and is very happy about the experience and insight he got from it. The book itself is repetitive at times, but that adds to the accessibility of the topic at hand when you jump right into a chapter. Additionally to the modularity and architecture aspects, you’ll learn OSGI through the code examples. This books gets a recommendation.

Book review: ATDD by Example

Another new book is from Markus Gärtner, of the Kent Beck signature series this time. It takes the reader by the hand and shows a way to use Cucumber, FitNesse and of course Behavior-Driven Development as a tool-and-process framework to implement (Acceptance-) Test Driven Development. None of our participants read the book fully yet, but it’s already a promising start. If you are looking for a new book about testing (after having read the great GOOS book), don’t hesitate. Another recommendation to read.

Visitor design pattern breaks modularization

One participant brought up the problem that he wanted absolute modularization in his application layout, but used a visitor design pattern at some central place. This breaks modularization, as the type information is exposed too much. We discussed the problem with some diagrams and sketches and came up with several alternatives, each with their own advantages and drawbacks. That was a great code design session among seasoned professionals.

Why are services included into Grails?

Another discussion was about the Grails web framework and the necessity for a service layer or service classes explicitly. We sketched out the fundamental architecture of a Grails application and discussed different possible alternatives to a dedicated service layer. There are some nice features about Grails services (like injection by convention, transaction and scope), but nothing really too sophisticated to distinguish them from POGOs. The discussion was open-ended, as usual with complex topics.

Review of a workshop on agile software-engineering

Lately, a participant visited a workshop on agile software-engineering, focussing a lot on SCRUM and XP. The workshop ran for several days and included lots of hands-on exercises. The workshop itself provided not much new content for seasoned agile developers, but served as an accurate and thorough introduction for younger developers. A major part of the workshop were social aspects of agile environments. Concepts like team empowerement are usually not taught in technical workshops. Important additional topics comprised of agile planning and estimation and proper retrospectives. The workshop itself was more of a entry-level introduction to agile development, but very effective in that regard.

Epilogue

As usual, the Dev Brunch contained a lot more chatter and talk than listed here. The high number of attendees makes for an unique experience every time. We are looking forward to the next Dev Brunch at the Softwareschneiderei. And as always, we are open for guests and future regulars. Just drop us a notice and we’ll invite you over next time.

An highly profitable investment

coinsWhen it comes to workplace ergonomics, oftentimes money matters most. And money is always short, except for a really good investment. A profitable investment is what every businessman will understand. Here is an investment that boosts both, ergonomics and finance.

The goal

In my definition, an highly profitable investment is money you get a return of an additional 25% in just a year. After that year, the investment does not vanish, but continues to pay off. The investment is socially acceptable at best: Everyone involved will feel happy as long as the investment runs. And the investment can be explained to every developer at your shop with just two words: dual monitors.

The maths

Ok, lets have some hard calculus about it. Here are some modest assumptions about the investment:

You already own a decent monitor, as you are a screen worker. Buying another one of the same type will cost you about 300 EUR, with 25% return on our investment, it needs to earn us about 400 EUR. A monitor that earns money?

Your income, without any additional costs for your employer, is at 40.000 EUR per year. If you happen to have an higher income, the investment just gets more profitable. You work for 200 days a year, according to the usual employment. If you look at the numbers, you see that you earn 200 EUR per day. The new monitor needs to earn two days worth of your work or one percent of your yearly working time.

If the monitor speeds you up by just one percent of your time, it’s a highly profitable investment.

A productivity boost by one percent

How much is one percent of your daily working time? If you work for eight hours a day, it’s about five minutes. You need to accelerate your work by using the second monitor by five minutes or one percent every day, that’s all. All the other goodies come for free: Better mood, higher motivation, lower defect rate, improved code quality.

Some minor limitations

We experimented with setups of N monitors, with N being a natural number. Three or more monitors do not pay off as much as the second one does. Hardware issues rear their ugly heads and generally, overview decreases. This might not be true with rapid context switching tasks like customer support, but with focussed software development, it is.

When using dual monitors, it’s crucial to get used to them and really utilize all their possibilities. Perhaps you might need additional software to fully drive your dual power home. You might have to rethink your application window layout habits.

Assigning a second monitor to a developer is an irreversible action. If you take it away again, the developer will feel jailed with too less screen real estate and might even suffer a mild form of claustrophobia. Morale and motivation will plummet, too.

Conclusion

Introducing dual monitoring to developers is a win-win situation for both the company and the developers. It’s a highly profitable investment while boosting staff morale and productivity. If there is one reason not to do it, it’s because of the irreversibility of the step. But a last word of secret to the management: You can even use it to raise employee loyalty, as nobody wants to work in a single monitor environment anymore.