woensdag 16 december 2009
Don't ask your child what he (she) did today, ask him what he learned today :-)
woensdag 2 december 2009
I just had two days of training on Scrum by the guru himself (Jeff Sutherland) and Serge Beaumont (Xebia). After doing XP for a while, I now can complement it with Scrum and have two legs to stand on ;-) I won't try to give a full account here what Scrum is, but it doesn't really cover the same stuff XP does. In one sentence you could say it's "extreme projectmanagement", or just "a framework for getting things done". The final goal is to get your team into "hyperproductive state".
The training was ok, I'd give it a 7.5/10. The material could have been presented a bit more structured (tell 'm what you're gonna tell 'm, then tell 'm, then tell 'm what you told them) but the content was ok. I appreciate the fact that they tried to support their story with data and referring to literature.
Completing this two day course (+exam) makes me a "Certified Scrum Master". After some more experience you can become a Certified Scrum Practitioner. Personally I would have switched those titles, but it's probably for historical reasons.
Already the next morning I noticed that I was unconsciously using some of the stuff. What's the business value of my wife opening the curtains when her goal is to get the kids to school on time? What's the business value of discussing a student who wants to enroll when he has missed the first 2.5 weeks of a quarter?
Let's keep this way of thinking and see if I can enter a hyperproductive state ;-)
vrijdag 13 november 2009
Today was another edition of the JFall. I took the light version by skipping the keynotes and not trying to score every goodie there was to get. ;-) As it turned out my programme had a high "Google" percentage. Coincidence or is the influence of Google spreading ever more?
I started out with "How to introduce Agile in my organisation?" (Erwin vd Koogh, Xebia). No revolutionary insights but a few nice twists to remember. The magic formula is Action = Pain x Budget and developers have to learn a new language (Businessy).
After that I took the hands-on lab on Google Android by Siarhei (Sergei) Dudzin. This worked like a charm and in 1.5 hours I got the feeling for what it takes to develop an application for a Google Android phone. What strikes me is the perfect documentation that Google has as compared to your average open source project. Of course they have the budget, but they really put in the effort.
The next one was about "five star projects" (Eric Bouwers, Software Improvement Group). Apparently there now exists an official certification for software maintainability by the German company TÜVit. This certification ranges from 3 stars to 5 stars. 1 star is rubbage. The SIG performs the investigation for TÜVit. Just as in education the accreditation institution is also seperated from the investigating institution.
The speaker demonstrated the metrics on several open source projects.
Java and Google App engine (Jettro Coenradie, JTeam) was the poorest talk from my perspective. Too little concepts and too much code and XML flashing by. "This is easy, this is just as easy, this is almost too easy to show." Apparently he had some other audience in mind than me.
But this was compensated for by the last talk on Google Wave (Jos Dirksen, Atos Origin). I'm already "waving" but this talk showed me a lot more features. Most people (including myself) start by using it as email, but it can do so much more. The big question at the moment seems to be how you want to use it once you've explored the many features.
Jos also showed how to build your own bots and gadgets. I hope I will have some experimentation time soon!
maandag 31 augustus 2009
The best way to keep up is to get some firsthand experience. That's why I will be involved in a project running within our researchgroup "New Business & ICT" (lector H. Velthuijsen).
The project aim is to deliver an expert system which will make life easier for Light Mentally Handicapped (LMH) people. This expert system is to be connected to all sorts of sensors within their homes and to be monitored by their attendants. If it works out well the LMH will need less interaction with their attendants, which gives the LMH a more normal life.
The client in the project is the NOVO foundation (www.novo.nl). Avics (www.avics.nl) is a market party involved with a lot of sensor/home automation expertise. The results will be open sourced.
My exact role will crystalize in a few weeks.
dinsdag 9 juni 2009
Saturday I had a party with my family in-law. Serge asked me whether I'd heard of "google wave" already. My interest was peaked and I checked it out on sunday evening on wave.google.com. I watched the entire 1h20 video of the demo at the google i/o conference.
There are two things I'd like to mention. First of all, I found the presentation pretty amateuristic. The presentation was pretty mediocre at some parts and the jokes were not really funny. How can I teach my students that they have to prepare decent presentations when even google's people don't do it? And the excuse "it was just a developer release" would be an insult to developers, I think. So I would have appreciated a 15 minute version with most of the chatter cut out.
But then the thing itself. Google Wave is a "communication and collaboration tool". In short, they set out inventing email as if they were inventing it today with all the technology at hand. But to say Wave is email, is not correct. It's like a combination of email, instant messaging, blogging, a photo site, wiki all in one. It integrates with your blog and your social network. You can collaborate with multiple people (demo was four) on a piece of text in real-time. It has playback functionality like walking through a revision history in source control. Etc. etc.
Google also thought about federation. This means companies will be able to set up their own wave-server and create wave-accounts just like you can do with mail. And open sourcing it after creating open API's means developers will be able to create extensions for waves at several levels (i.e. at product or protocollevel).
So did google succeed in impressing me? Yes! (Despite the crummy presentation :-)
donderdag 28 mei 2009
Yesterday I attended a NLJUG university session at Sun Amersfoort. Topic was Glassfish v3 which is coming soon. Glassfish is Sun's open source application server.
While most of the technical details went too deep for me (I'm not using this stuff on a daily basis) I tried to grasp the main line. For me it's the focus on the two stakeholders: developers and system managers. For the system managers clustering is pretty easy now and they also demo'd SNMP support. For the developers it's very handy that you can fix a bug, save the file and then test your webpage again without restarting the appserver and needing to recreate the testsituation. You just refresh the page and it all works, your entire session is kept intact.
But Java EE development is still pretty complex. How much emphasis should we put on all the tools and technical details as opposed to logic and creating maintainable applications?
woensdag 6 mei 2009
Unfortunately my presentation on use cases at the RDW was scheduled quite close on my NIOC presentation. This meant working the entire Easter holidays on the presentation, which included a screening of the use of Use Cases in a particular project. My most relevant find was that they were keeping track of requirements (functional and non-functional), scenarios, use cases (twice, with slightly different titles) and all the mappings between them. Of course it's all useful information but in the end it looked a bit too much overhead to me.
The presentation itself left me with mixed feelings. My public was attentive enough but didn't really react at the end. However, later that day I was at the UMCG and came into contact with a lady who works as a functional designer. We immediately connected on the subject of use cases and I could give her my handouts which were still in my pocket. I felt like I still got some reward for my efforts.
woensdag 1 april 2009
I haven't looked at the programme yet, since I'm concentrating on my own contribution. I will be giving a talk about architecture and my learnings at the RDW. My concept title was "Architecture, do you need to have grey hair?". I tried to get it changed later on, but somehow it stuck on the site....
zaterdag 21 maart 2009
Software Architecture in Practice (2nd edition, 2003, Bass e.a.)
A classic book by the SEI, which gives a good introduction to software architectures and the different issues around them (achieving qualities, architecture lifecycle, analysis and tradeoffs, etc.) For our bachelor students it would be a bit 'dry', also the case studies are somewhat dated.
Pattern-Oriented Software Architecture (1996, Buschmann e.a.)
Also a classic, still readable at this age. The focus is mostly on the 'pattern' part (architectural patterns and design patterns). It could use a second edition to get in sync with the developments in the pattern-field. Readers would need to complement this book with another introductory text. At the RuG (master Computer Science) this book is used in combination with the previous one.
Software architecture - Foundations, Theory and Practice (2009, Taylor e.a.)
A very complete and uptodate book on all aspects of software architecture. For me however it was too academic, after the first couple of chapters I started browsing instead of reading.
And my winner is ...
Software Systems Architecture - working with stakeholders using viewpoints and perspectives (2005, Rozanski e.a.)
I liked this book best. It introduces the subject from a practical angle, still covering all the issues. After the introduction (architecture, architect, process, viewpoints and stakeholders) comes a catalog of viewpoints (like RUP's 4+1, but more) with advice about problems and pitfalls. Then the authors progress towards 'perspectives', the term they use to denote the quality issues. You can read this book as a textbook and then use the catalogues for reference (just like Fowler's Patterns for Enterprise Application Architecture).
But I still see a market for a text book with more real life examples and exercises. Anyone?
zaterdag 21 februari 2009
There's an amusing resemblance between how Enterprise Architecture is seen at the RDW and the phrase "The [software] architecture establishes constraints on downstream activities, and those activities must produce artifacts [...] that are compliant with the architecture, but architecture does not define an implementation."
Maybe there's not that big a difference between Software Architecture and Enterprise Architecture after all? (On SA versus EA you could also look at this one.)
woensdag 11 februari 2009
I've neglected this blog since I started my work at the RDW. This doesn't mean there nothing was learned, on the contrary! I'm getting such a lot of experiences that I couldn't possibly mention them all. I'm learning about architecture but also a lot of collateral stuff. But for now I'll just mention some points about architecture.
In Q1 I took lectures at the RuG on software architecture, but at the RDW it's all about "enterprise" architecture. This is the domain of fuzzy talks, large scale models, handwaving and the like, but when you are in the domain a bit longer it becomes clearer. I now feel I can cut away the clouds and move more towards the essence. It's all about structuring, reducing complexity and enabling change in the long term. And all that on the scale of the entire enterprise instead of a single system. In this regard I can really recommend the DYA book "Building an enterprise architecture practice" (or "Stap voor stap op weg naar een professionele enterprise architectuur" in Dutch). I read it when I started here, and recognized a lot of situations here. In fact the first meeting at the RDW seemed a literal replay of a fictional case in the book. I will reread it when I´m finished.
On the part of software architecture, the RDW isn´t as far yet as their work on enterprise architecture. Put in one sentence I see software architecture as capturing the essential requirements (use cases AND non-functional requirements) from the different stakeholders and then making the fundamental design decisions how to reach those. Of course RDW works on these things but not everything is explicit and every project or even person has his own way of working and documenting on these issues.