Yesterday, we held another Schneide Dev Brunch on our roofgarden. 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.
We had to do another introductory round because there were new participants with new and very interesting topics. This brunch was very well attended and rich in information. Let’s have a look at the main topics we discussed:
Agile wording (especially SCRUM)
This was just a quick overview over the common agile vocabulary and what ordinary people associate with them. A few examples are “scrum“, “sprint” and “master”. We agreed that some terms are flawed without deeper knowledge about the context in agile.
Book: “Please Understand Me”
if you are interested in the Myers-Briggs classification of personality types (keywords: are you INTJ, ESTP or INFP?), this is the book to go. It uses a variation of the personality test to classify and explain yourself, your motives and personal traits. And if you happen to know about the personality type of somebody else, it might open your eyes to the miscommunication that will likely occur sooner or later. Just don’t go overboard with it, it’s just a model about the most apparent personality characteristics. The german translation of the book is called “Versteh mich bitte” and has some flaws with typing and layouting errors. If you can overlook them, it might be the missing piece of insight (or empathy) you need to get through to somebody you know.
TV series: “Dollhouse”
As most of us are science fiction buffs and hold a special place in our heart for the series “Firefly”, the TV series “Dollhouse” by Joss Whedon should be a no-brainer to be interested in. This time, it lasted two seasons and brings up numerous important questions about programmability every software developer should have a personal answer for. Just a recommendation if you want to adopt another series with limited episode count.
A new concept of collaborative programming is “wolfpack programming” (refer to pages 21-26). It depends on a shared (web-based) editor that several developers use at once to develop code for the same tasks. The idea is that the team organizes itself like a pack of wolves hunting deer. Some alpha wolves lead groups of developers to a specific task and the hunt begins. Some wolves/developers are running/programming while the others supervise the situation and get involved when convenient. The whole code is “huntable”, so it sounds like a very chaotic experience. There are some tools and reports of experiments with wolfpack programming in Smalltalk. An interesting idea and maybe the next step beyond pair programming. Some more information about the editor can be found on their homepage and in this paper.
Book: “Durchstarten mit Scala”
Sorry for the german title, but the book in this review is a german introductory book about Scala. It’s not very big (around 200 pages) but covers a lot of topics in short, with a list of links and reading recommendations for deeper coverage. If you are a german developer and used to a modern object-oriented language, this book will keep its promise to kickstart you with Scala. Everything can be read and understood easily, with only a few topics that are more challenging than there are pages for them in the book. The topics range from build to test and other additional frameworks and tools, not just core Scala. This book got a recommendation for being concise, profound and understandable (as long as you can understand german).
Free Worktime Rule
This was a short report about employers that pay their developers a fixed salary, but don’t define the workload that should happen in return. Neither the work time nor the work content is specified or bounded. While this sounds great in the first place (two hours of work a week with full pay, anybody?), we came to the conclusion that peer pressure and intrinsic motivation will likely create a dangerous environment for eager developers. Most of us developers really want to work and need boundaries to not burn out in a short time. But an interesting thought nevertheless.
Experimental Eclipse Plugin: “Code_Readability”
This was the highlight of the Dev Brunch. One attendee presented his (early stage) plugin for Eclipse to reformat source code in a naturally readable manner. The effect is intriguing and very promising. We voted vehemently for early publication of the source code on github (or whatever hosting platform seems suitable). If the plugin is available, we will provide you with a link. The plugin has a tradition in the “Three refactorings to grace” article of the last Dev Brunch.
Light Table IDE
A short description of the new IDE concept named “Light Table”. While the idea itself isn’t new at all, the implementation is very inspirational. In short, Lighttable lets you program code and evaluates it on the fly, creating a full feedback loop in milliseconds. The effects on your programming habits are… well, see and try it for yourself, it’s definitely worth a look.
Inventing on Principles
Light Table and other cool projects are closely linked to Bret Victor, the speaker in the mind-blowing talk “Inventing on Principles”. While the talk is nearly an hour of playtime, you won’t regret listening. The first half of the talk is devoted to several demo projects Bret made to illustrate his way of solving problems and building things. They are worth a talk alone. But in the second half of the talk, Bret explains the philosophy behind his motivation and approach. He provides several examples of people who had a mission and kept implementing it. This is very valuable and inspiring stuff, it kept most of us on the edge of our seats in awe. Don’t miss this talk!
Albatros book page reminder (and Leselotte)
If you didn’t upgrade your reading experience to e-book readers yet, you might want to look at these little feature upgrades for conventional books. The Albatros bookmark is a page remembering indexer that updates itself without your intervention. We could test it on a book and it works. You might want to consider it especially for your travelling literature. This brought us to another feature that classic dead wood books are lacking: the self-sustained positioning. And there’s a solution, too: The “Leselotte” is a german implementation of the bean bag concept for a flexible book stand. It got a recommendation by an attendee, too.
If you ever wondered what you just read: It might have been bullshit. To test a text on its content of empty phrases, filler and hot air, you can use the blabla-meter for german or english text. Just don’t make the mistake to examine the last apidoc comments you hopefully have written. It might crush your already little motivation to write another one.
Review on Soplets
In one of the last talks on the Java User Group Karlsruhe, there was a presentation of “Soplets”, a new concept to program in Java. One of our attendees summarized the talk and the concept for us. You might want to check out Soplets on your own, but we weren’t convinced of the approach. There are many practical problems with the solution that aren’t addressed yet.
Review on TDD code camp
One of our attendees lead a code camp with students, targeting Test Driven Development as the basic ruleset for programming. The camp rules closely resembled the rules of Code Retreats by Corey Haines and had Conway’s Game of Life as the programming task, too. With only rudimentary knowledge about TDD and Test First, the students only needed four iterations to come up with really surprising and successful approaches. It was a great experience, but showed clearly how traditional approaches like “structured object-oriented analysis” stands in the way of TDD. Example: Before any test was written to help guide the way, most students decided on the complete type structure of the software and didn’t aberrate from this decision even when the tests told them to.
Report of Grails meetup
Earlier last week, the first informal Grails User Group Karlsruhe meeting was held. It started on a hot late evening some distance out of town in a nice restaurant. The founding members got to know each other and exchanged basic information about their settings. The next meeting is planned with presentations. We are looking forward to what this promising user group will become.
This Dev Brunch was a lot of fun and new information and inspiration. As always, it had a lot more content than listed here, this summary is just a best-of. 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.
8 thoughts on “Summary of the Schneide Dev Brunch at 2012-05-27”
The concept behind light table goes way beyond just using an immediate feedback loop inside an IDE. The idea is to craft your own specific IDE to suit your needs for your task at hand, your programming language and style. See http://www.chris-granger.com/2012/05/21/the-future-is-specific/ for further info
Bret Victor’s work is important and very well implemented, I think. It would be even greater if he would mention the source of some ideas, e.g. those coming from Smalltalk IDEs, such as
– multiple editors with just one function in it;
– show code in an “area of concern” not just in a file;
– the coding environment can show also results;
– trying is encouraged, and you get instant feedback on code changes.
These and further points can be found at http://news.ycombinator.com/item?id=3836978.
I think at least one thing is missing in Smalltalk IDEs and even in LightTable which is shown in Bret’s talk: changing parts of the code on the fly. He moves numbers with the mouse and sees things (like the wind in the leaves) which cannot be seen when you edit the numbers by hand (typing).
Yup, I think most Smalltalk IDEs are quite mouse intense, and LightTable seems so, too. Since Bret preaches direct interaction, you have a point there.
Watching his talk “inventing on principles” mentioned above, especially his attempts to aim Mario into the small gap, my suggestion for even more direct interaction would be some kind of “symbolic execution”: mark the value that you want to change as “symbolic”, let the IDE compute the change vector and thus enable the user to do the manipulation of the value in the RESULT window, e.g. grabbing & moving Mario with the mouse. Is this idea already mentioned in his essay from 2006?
In his paper from 2006 he does not talk about a game or an IDE, but he talks about an environment where the software learns via simple machine learning algorithms like last value prediction to derive what is intended. In his example he uses a train schedule, the designer of the software draws or drags a rectangle to show the start and the length of the trip which then the software correlates to the train schedule. Then he uses colors for the different train lines and the software automatically derives that different colors mean different lines and so on. It is an interesting read, give it a try, you don’t need to read it in one session.
And I think Bret’s demo is just for the sake of it, he did not even publish the source or something like it. He just uses it as a demo to show what it can look like when you are following your principle. Read his essay from 2006 http://worrydream.com/#!2/MagicInk for further ideas
Hej guys, I hosted Code Readability on github https://github.com/InSL/Code_Readability. Feel free to join my little project.
Thank you very much for this post. I enjoyed reading it, especially the part about inventing on principle and the bullshit-meter. Just used it to analyze the text on our company’s site… 😀