Nederlands (NL-nl)English (United Kingdom)
Free talk with Philippe Kruchten
Written by Arne Timmerman   

You're all cordially invited to a free talk with Philippe Kruchten next wednesday, December 19th, from 15:30 to 16:30. The talk on cognitive biases in software development will take place at the TU Delft, EWI, Lipkens room.

Over the years we've identified some of the strategies and tactics software architects use during the design of new, bold, large software-intensive systems: divide-and-conquer, brainstorming, reuse, etc.. But we also observed some strange tactics, biases, reasoning fallacies that creep in and pervert somehow the design process. They go by simple, funny or fancy names: anchoring, red herring, elephant in the room, post hoc ergo propter hoc, non sequitur, argumentum verbosium, etc. This talk will do a little illustrated catalogue of these games, with examples, and how they sometimes combine onto subtle but elaborate political plots. In other words, this talk is about cognitive biases and how they affect software development.

Philippe Kruchten

Philippe Kruchten is professor of software engineering, in the department of Electrical and Computer Engineering of the University of British Columbia, in Vancouver, where he holds an NSERC Chair in Design Engineering. He teaches software engineering, more specifically software project management, and two interdisciplinary project courses on innovation, entrepreneurship, system engineering. Philippe does research in software architecture and software processes, with a handful of graduate students, and many collaborators around the world. He is known as Director of Process Development (RUP) at Rational Software, and developer of the 4+1 view model.

Report Global Day of Coderetreat AMS 2012
Written by freek   

This review was written by Linda van der Pal and is cross-posted from the Duchess blog on

Yesterday I traveled through the cold over icy pavements to the office of Mirabeau in Amsterdam to join my fellow coding enthusiasts for a day of mad coding. There I was joined by about twenty others and even eight children. The younger children set out to learn the Scratch programming language, while the older 'kids' went off to play with the game of life. For them (including me) the day was divided into iterations of about 45 minutes. In our first iteration we attempted to write the game using TDD as if you meant it. Which has three easy rules.

1. The code is written in the test
2. You may only extract a method when you get duplication
3. You may only extract a class when several methods share the same state, that is not shared by yet other methods.

This turned out to be rather hard to do as it's contrary to the way most of us work all the time. This iteration I joined someone who was programming in Python, as I hadn't brought my own laptop. We didn't get very far, as we found it rather hard to determine what our first test should do. It took us at least fifteen minutes to get started properly. In the end we only had two test methods determining whether a cell was dead or alive (although there was no real concept of cell yet) and four test methods to determine if two cell were neighbors. After the 45 minutes were done, we had to delete our test and then discussed what approached we had all tried. Some had, like us, chosen the bottom-up approach, while other had chosen a top-down approach and had started with a complete board.

As most people found this round very hard, we did another round with the same constraints. This time I joined someone who was using JavaScript. We got a bit further during this round, as we'd done some of the groundwork in the previous round. Again we went for the approach of determining if two cells were neighbors. We even got so far as to attempt to wrap around the edges of the board. But there we made a slight error in our formula while redesigning (as it was real refactoring) and had failing tests when the 45 minutes were over. Once again we had to delete our code. But when we discussed a bit more about what we had been doing, we decided that we had been going about the wrong approach and that it would be better if we had asked what the neighbors of a certain cell were, as this would be much easier to calculate and much more useful.

After the second round, it was time for lunch. But not before the younger children gave a little demo of what they had been doing during the morning. It turned out that what they had built on the demo laptop had not been saved properly, but the laconic answer was "Oh, no matter, I'll just build it again." Which is something we can all learn from, I'm sure! And indeed the demo was quickly put together again and they showed us some animals flying over the screen and turning around when they got to the edge of the screen. Very impressive when compared to our own paltry results of the morning!

After an excellent lunch I was curious about Scratch myself and so I skipped an iteration to go see what the kids were up to. They were just starting with a game of their own. They were going to make a game where a character had to catch something and would score points if he did, and lose points if he didn't. The requirements of such a game were quickly established and written on a whiteboard. Then the kids paired up and set to write the game. After about an hour they all had most of the requirements implemented.

I left them to it, and went back to another iteration of coding. This time I joined up with someone coding in C# and the constraint was not to return anything. Which was once again quite contrary to my own coding style. And also could not be combined with the TDD as if you meant it style we had been using before. Fortunately my partner had quite some experience with delegates and we passed our one-liner assertions on to the methods under test. At the end of the iteration it turned out we had the most tests of all the groups and as we hadn't yet deleted our code right away (as we were supposed to) we code showcase it to the rest of the group.

For the final round of the day I got to program in Java (which is the language I use daily) with the constraint not to use any conditionals. So no for-loops, no while, and most importantly no if. This turned out to be such a conceptual leap that we couldn't really code test driven anymore. But after some pondering we figured out that you could put the conditional rules of the game in a map. Where you could simply look up the answer of whether a cell would live or die by passing in the number of living neighbors it had. We then counted the number of living neighbors by putting all the neighbors in a list and determining the frequency of living cells in it. We were sure that the frequency method must use conditionals under water, but it saved us from using conditionals ourselves. We ran out of time one final time, but at least we could save our code this time. Once again we discussed the results at the end of the round. This time the results were even more varied, as the solution really depended on what kind of constructs the language offered.

Then it was time for the kids to showcase their games and they were really impressive. One pair had created a game with a squirrel in a forest who had to catch nuts (yet avoid the spiky chestnuts). One team had a shark in the sea catching fish. The third team had created a ghost who had to catch dinosaurs. And the fourth team had a crab running to catch apples. If you want to play their games, you can at:

Then it was time for a last cup of coffee, a short evaluation round, a handing out of code smell cards by QWAN, and finally to say goodbye. All in all it was a great day, and I can't wait for the next one.


Verslag Back to School - Software security
Written by freek   

Dit verslag is geschreven door Joep Joosten(@joepjoosten). Bedankt Joep!

Verslag van de Devnology Back to School bijeenkomst 7 nov 2012 bij de Radboud Universiteit in Nijmegen.

Afgelopen jaren zijn veel beveiligingslekken in allerlei soorten software en hardware gevonden. Sommige van deze lekken halen zelfs het nieuws, getuige deze headlines: "EenVandaag: nieuwe pinnen onveilig", "NOS: Gebruik Internet Explorer niet", "NOS: Journalist vrijuit na kraak ov-chip", en deze: "NOS: Analfabete Ethiopische kinderen hacken tablets".

Hoe kan dit keer op keer gebeuren? Dit heeft te maken met de focus van de ontwikkelaar. Er wordt vaak pas na het in productie nemen van de software / hardware gedacht aan de beveiliging, of zelfs helemaal niet. Software engineers en gebruikers zijn vaak alleen maar gefocust op de functionele aspecten van de programmatuur. Hoe vaak wordt er door de opdrachtgever gevraagd om veilige software? Dit is in het algemeen een aanname die wordt gemaakt door de opdrachtgever.
Bewustwording bij software engineers is een van de aspecten om software veiliger te maken. Belangrijke hulpmiddelen hiervoor zijn o.a. de top 10 lijst van de meest gemaakte beveiligingsfouten opgesteld door OWASP (Open Web Application Security Project).

In de sessie Software Security van het Back to School programma traden er twee sprekers op die elk vanuit een eigen invalshoek ons bewuster van dit fenomeen gemaakt hebben.

Zo verteld Walter Belgers tijdens zijn lezing dat deze top 10 van de lijst met meest gemaakte beveiligingsfouten de afgelopen jaren maar weinig wijzigingen heeft gekend. Dat betekend dat we keer op keer dezelfde fouten blijven maken. Walter heeft de lijst met ons doorgenomen en van voorbeelden voorzien. Ook vertelde hij over handige hulpmiddelen om je eigen computer netwerk, servers en software te testen op bestaande beveiligingslekken.

De tweede lezing werd verzorgd door Erik Poll. Bij binnenkomst liet hij direct zien dat de verschillende smartcards, zoals je id-kaart, paspoort of chip-knip, eenvoudig zijn uit te lezen. Met zijn eigen demo opstelling las hij heel eenvoudig mijn id-kaart uit. Hij heeft zelfs een app op zijn nfc smart-phone die in staat is hetzelfde te doen. In zijn lezing legde hij uit hoe een smartcard werkt, en hoe de beveiliging van verschillende smartcards te kraken is. Dit kan softwarematig, maar het is ook mogelijk om de beveiliging bloot te stellen door er fysiek met een laser op te schieten. Er zijn volgens Erik veel smartcard makers die een eigen encryptie methode maken. Dit zijn precies de smartcards die eenvoudig te kraken zijn, want deze voldoen niet aan het "principe van Kerckhoff".

Om je niet helemaal ongerust te maken: Walter en Erik zien wel dat er steeds beter wordt gelet op beveiliging. De beveiliging verbeterd en de methodes om software en hardware te kraken worden steeds ingewikkelder en duurder. Hierdoor wordt het minder aantrekkelijk om dit deel van de keten te misbruiken. Kwaadwillende stappen dan, onder de naam "social engineering", over op andere methodes. Bij deze techniek maken hackers gebruik van de zwakste schakel in computerbeveiliging, namelijk de mens.



<< Start < Prev 1 2 3 4 5 6 7 8 9 10 Next > End >>

Page 4 of 29


Prijzen sponsors

JetBrains logo


Bekijk alle foto's van Devnology op Flickr.

Why meet up?

Devnology meetings are aimed to bring together passionate developers to exchange ideas and experience, to discuss and network - geek to geek.

About us

We focus on concepts of software development. For new developments we will dig into the underlying principles and concepts and try to place this in a broad perspective of existing platforms and solutions. Read more...