Talk started with a good explanation of a common problem. But it soon turned into an introduction of UML. Perhaps this talk should have a different title? Kudos for the Lego time lapse though!
There's a strong conflict between Agile (as commonly practised) and design up front (as per waterfall)... but each approach has strengths and weaknesses. Harrie explained how a small amount of design up front can help benefit a system designed in an agile environment (being able to write tests up front, and being able to visualise how the system will hang together, being able to model the effects of refactoring on paper before making code changes, etc) while limiting the sheer volume of design up front more commonly associated with waterfall.... taking the best elements from both approaches.
I agreed with the general theme of the talk, but felt that the level of detail on how to write UML was distracting from the overall theme of the talk - especially as Harrie went on to say much of it he doesn't use.
I loved the Lego stopmotion example, and would have liked to see more hand-drawn diagrams in the second half of the talk.
A bit more discussion of diagramming the system architecture vs class-level code architecture would have been nice too.
The lego was great, as was the premise of the talk. The detailed guide to UML didn't seem relevant, particularly as Harrie went on to say how he cut it down for day to day use. The talk would be much improved by cutting the UML tutorial in favour of real world examples of where Harrie used the cut down diagrams to solve problems.
I think there was a very good message in this talk, but it didn't need as in depth a description of UML. Modelling, and a general emphasis on design first development, is something that is often lost in the 'agile' software development lifecycle. These are all still valuable tools for a developers toolbox.
From the title alone I would have expected the content of the talk to be more focused on actual application architecture, but as Volker pragmatically pointed out in the closing keynote, "it depends" would be the default answer anyway.
In my experience, using diagrams has helped a lot, but I've not yet used them in an agile context.
I fully agree, though, that more time should be spent on actually designing the architecture of an application and especially discussing it.
I really struggled with this talk, which essentially seemed to be wholly about using UML. The start was great, particularly the Lego elements and having seen you speak before, I was looking forward to an energising and enjoyable talk. Sadly once the UML started, I couldn't engage any more. It would have been better for me if you'd done a brief section there and then moved on to some other concepts. Thanks though :)
Well delivered. Would probably have given it a miss if I had known it was about using the best bits of UML to augment agile but only because that's what I already do.
I've never really got to grips with UML - it's always been on my 'ought to' list. So this was helpful - although I agree with the other comments that a worked example would be really valuable. Starting with a blank sheet of paper, and then going through a 'real life' project up to the point you start writing code.
The talk started off very well with an engaging explanation of why some degree of design and forward planning is required, but once it got to the UML I basically switched off. I feel the talk would have been more valuable with more information about the integration of design tasks into an agile process and problems that you may encounter, and less about the actual design documents themselves.
I guess I was expecting more about the what and the why of software architecture in a world where Agile is the thing. We did get some of the why which was very good. The speakers still was nice and relaxed and the "build a house" video was great - so true!
Worth hearing as a reminder that just because we don't do waterfall any more (yeah right!) there are still parts of that process that can, and should, be adapted to whatever process you adopt to replace it. Agile involves breaking the work down into smaller more manageable chunks, and so why not do that with the design too?
Very well presented talk, had expected a few more general tips to help avoid the lego-stairs-in-the-bathroom scenario. Instead the second half got a bit bogged down in explaining UML, which I'm sure most of us have done before. Still, a useful reminder that UML doesn't have to be an overly-detailed spidery type of documentation but in a less formal form can be a quick way of helping devs visualise things before they jump in.
Got off to a really good start with the Lego illustration, but then seemed to dig too much into detail of diagraming things in UML in the second half.
Felt to me it would have been better to stick at the higher level with some more abstract examples about fitting Software Architecture into Agile Methodologies (which is something we are wrestling with at work, with 3-4 scrums all working on the same code base but little overall architecture design)
Comments
Comments are closed.
Talk started with a good explanation of a common problem. But it soon turned into an introduction of UML. Perhaps this talk should have a different title? Kudos for the Lego time lapse though!
There's a strong conflict between Agile (as commonly practised) and design up front (as per waterfall)... but each approach has strengths and weaknesses. Harrie explained how a small amount of design up front can help benefit a system designed in an agile environment (being able to write tests up front, and being able to visualise how the system will hang together, being able to model the effects of refactoring on paper before making code changes, etc) while limiting the sheer volume of design up front more commonly associated with waterfall.... taking the best elements from both approaches.
I agreed with the general theme of the talk, but felt that the level of detail on how to write UML was distracting from the overall theme of the talk - especially as Harrie went on to say much of it he doesn't use.
I loved the Lego stopmotion example, and would have liked to see more hand-drawn diagrams in the second half of the talk.
A bit more discussion of diagramming the system architecture vs class-level code architecture would have been nice too.
Good tips on agile software architecture with visual examples of what happens when things are not thought - loved the Lego example, relaxed
The lego was great, as was the premise of the talk. The detailed guide to UML didn't seem relevant, particularly as Harrie went on to say how he cut it down for day to day use. The talk would be much improved by cutting the UML tutorial in favour of real world examples of where Harrie used the cut down diagrams to solve problems.
I think there was a very good message in this talk, but it didn't need as in depth a description of UML. Modelling, and a general emphasis on design first development, is something that is often lost in the 'agile' software development lifecycle. These are all still valuable tools for a developers toolbox.
From the title alone I would have expected the content of the talk to be more focused on actual application architecture, but as Volker pragmatically pointed out in the closing keynote, "it depends" would be the default answer anyway.
In my experience, using diagrams has helped a lot, but I've not yet used them in an agile context.
I fully agree, though, that more time should be spent on actually designing the architecture of an application and especially discussing it.
I really struggled with this talk, which essentially seemed to be wholly about using UML. The start was great, particularly the Lego elements and having seen you speak before, I was looking forward to an energising and enjoyable talk. Sadly once the UML started, I couldn't engage any more. It would have been better for me if you'd done a brief section there and then moved on to some other concepts. Thanks though :)
Well delivered. Would probably have given it a miss if I had known it was about using the best bits of UML to augment agile but only because that's what I already do.
I've never really got to grips with UML - it's always been on my 'ought to' list. So this was helpful - although I agree with the other comments that a worked example would be really valuable. Starting with a blank sheet of paper, and then going through a 'real life' project up to the point you start writing code.
The talk started off very well with an engaging explanation of why some degree of design and forward planning is required, but once it got to the UML I basically switched off. I feel the talk would have been more valuable with more information about the integration of design tasks into an agile process and problems that you may encounter, and less about the actual design documents themselves.
I guess I was expecting more about the what and the why of software architecture in a world where Agile is the thing. We did get some of the why which was very good. The speakers still was nice and relaxed and the "build a house" video was great - so true!
Worth hearing as a reminder that just because we don't do waterfall any more (yeah right!) there are still parts of that process that can, and should, be adapted to whatever process you adopt to replace it. Agile involves breaking the work down into smaller more manageable chunks, and so why not do that with the design too?
Very well presented talk, had expected a few more general tips to help avoid the lego-stairs-in-the-bathroom scenario. Instead the second half got a bit bogged down in explaining UML, which I'm sure most of us have done before. Still, a useful reminder that UML doesn't have to be an overly-detailed spidery type of documentation but in a less formal form can be a quick way of helping devs visualise things before they jump in.
Got off to a really good start with the Lego illustration, but then seemed to dig too much into detail of diagraming things in UML in the second half.
Felt to me it would have been better to stick at the higher level with some more abstract examples about fitting Software Architecture into Agile Methodologies (which is something we are wrestling with at work, with 3-4 scrums all working on the same code base but little overall architecture design)
I found the talk a little UML heavy, which lost its relevance to me a little.
The rest was great, including the lego house representation. I was hoping for more of the general advice though.