Geeks With Blogs
Evil Dev's Blog Plots, Schemes, and Plans to take over the Devleoper world.... Mu hahahaha
Well, today I had the honor of attending the first annual SDEC09 Conference hosted by Protegra. This event was similar to the Winnipeg Code Camp, where they had three trains of presentations going on all day. Well, it was a wonderful conference, well worth the $100 Early bird price, as I had a chance to sit in on some amazing presentations.

Let's take a look at some of the topics presented that I attended.

Introduction to Agile Developement - Presented By Steve Regalsky

Well, I've heard of Agile Development, especially recently, but I've not really had a chance to get into it all that much. I decieded to sit in on this presentation, as it is something I've been hearing a lot about recently, and my natural curiosity struck me to listen in.

Basically, the idea is to have a different, more flexible approach to software development, a method that welcomes change and takes iterative development to the extremes. Now, the way I interpret it based on the presentation, is essentially communication is key. I mean, duh right? Communication is something we must do, lack of communication often tends to lead to what being built is not what's requested by the client and projects get rejected. One of the things agile strives for is a very team centric development practise, not just a team of developers lead by a project manager, but have every participant from the client to the user to the developer all working in collaboration. This to me, just makes sense, I mean unless you have an opportunity to talk with the user how can you know what they want?

In my experience developing, typically it's a "no-no" to talk with the client. That's what MD and BA's are for. The BA delegates a requirements doc to the Project manager who refines it into a scope of work and then plans/passes the SOW to the developer who's job is to build it.

The agile approach is a little different, the requirements, and the SOW aren't typically used, instead your development should be designed and open to the changes of the business. Let's face it, a lot can change in a business in 3 months time, and on a long development project especially, what the needs of the business are at the start of the project, are not necessarily what's needed by the end of it.

Also, it is quite common for the client not to really have a clue what they want, they just need something. Agile strives to build small, short iterations and deliver a working prototype often and as quickly as possible, while leaving it open for adaptation. The sooner in a development life cycle a client can play with his new toy, the sooner you find out what he really wants and what doesn't matter as much to him/her.

Agile, despite popular belief, is not a "Defined Way to do things" but more of a strategic approach to solving a problem. Software development doesn't need to "follow the rules to the T" but just to encourage communication amoungst all levels of a project, to produce the most value with the least amount of code possible. It's not about delivering a specific project, sure in a perfect world when requirements are done up the needs of the business stay constant, but the reality is the needs of any business are constantly changing.

Lean Software Development - Kickoff To Deployment in 92 days - Presented by Terry Bunio

In this topic, the presenter, Terry, walked us through the steps they took to deliver a project to a client, applying Lean Development and Agile Principals in a real world example. He covered a lot of stuff in a broad spectrum of areas, and while I'd like to get more detailed into some of the topics, he did an excellent job of a highlevel process.

What I took back from this presentation is a deeper understanding of how Agile is applyed in a real world scenario, and I find it seems to rely heavily on a well assembled team. You need every member of the team to pursue a specific role, yet be well rounded enough to grasp all other areas of the development process.

As this topic was closely related to the first topic, I won't go into too much detail, but his presentation materials are supposed to be made available on the SDEC09 Website by Friday, I'll post a link as soon as their available.

Introducing Inversion of Control and the Microsoft Unity Application Block - Presented by Uwe Schmitz

First off, Uwe is an amazing presenter. I've been to a few of his presentations in the past, they are always very informative, and fun to attend. I had a chance to see him do some stuff with the Unity Framework at his last User group meeting, but in this presentation it was more the focus.

What I took back from this presentation, is surprisingly not that "unity is the answer to all your problems" but a more solid understanding of Inversion Control, and the importance of decoupling your code as much as possible. Unity, fits in really well with typical agile techniques, such as TDD, and mocking, and it decouples your code, removes dependencies and generally helps abstract away the how for the why. The idea is to make your code more change friendly, maximizing the use of interfaces and auto-instantion. Instead of asking for a FileLogger, you ask unity for a "logger" and it gives you an instance of ILogger that you can use for logging. This way, if the business requirements change, and say errors need to be logged to the eventlog, it's a simple configuration change and bam, it's no longer logging to a file, but logging to the eventlog, without the need to recompile. You can even drop an entirely new DLL into the BIn folder and configure it to use a 3rd party impementation of ILogger.

This is definately a topic I'm going to dig more into, change resilliant code is a requirement in todays fast paced business market, and the easier you can accept changes, the better it is for you and your clients, and that helps both you and your client to succeed. And that my friends, is what software development should be about. It the client isn't happy, then no matter how pretty your code, you did a crap job.

Aspect Oriented Programming Using Spring - Presented by Cory Maksymchuk

Well I'm typically not a Java developer, I haven't really touched java since college, but I took a lot out of this presentation. I think I overheard that it was Cory's first presentation like this, but although he seemed a little nervous at first, it was hard to tell. He did an excellent job of presenting, and was very knowledgable about the topic.

I believe the first time I heard about Aspect Oriented Programming, it was a presentation done by Donald Belchman at the winnipeg code camp, based on PostSharp. The idea behind it is, there's always certain parts of your application that can't be separated into specific layers, because they affect all layers of your application, called "Cross Cutting Concerns". These are thing such as logging, security, benchmarking whatever, things that should/may happen at all layers of your application.

This is a topic I'm really interested in, although I haven't come up with a personal oppinion on the best way to do this. What Cory demoed was Springs approach to solving this problem. Spring is a Java framework that injects code in at runtime, through dynamic inheritance. In some ways it's similar to Unity, in that it abstracts away class/interface through dependency injection. But it's also similar to Castle Windsor in that it's configurable, you can turn aspects on and off without recompiling, and you don't have to put your trust into a 3rd party library directly injecting code into your DLL. There are disadvantages, you can only apply aspect code to Public, inheritable classes, but all in all, looks like a worth while technology.

Estimating Using Planning Poker - Steve Regalsky

This was a really fun presentation. It wasn't really a presentation, but more like a hands on Lab. We were shown an Agile approach to estimating first hand, and it was lots of fun.

Of all the topics I attended today, this is the one that has the most potential to affect the way I work short term I think. Instead of the current system where the client asks for something, MD then sends the requirements to the BA who creates the SOW and then sends to the project manager who goes to the developer to get estimates, and then it flows all the way back up to the developer, Agile takes a different approach. Everyone is involved in the estimation of the project, from the developer to the client, and I think this is an EXCELLENT idea for any company. It also makes it fun, but using cards.

Essentially you get a list of "User Stories' form the client giving general advice on what they want, and then you discuss how much effort is involved to do each step. Not a time estimate, instead, you give them a rank on a point system, which groups scenarios into categories of similar workload.

Also, you get the entire team together, the client included, to rate them on complexity. Each member of the team selects a card with the number of points they feel each scenario is worth in complexity, and then everyone reveals their card. This sounds silly, but it's surprisingly effective, because for example, if the client gives a task a 1 in terms of complexity, and the developer gives it an 8, it sparks a debate with the client to bring awareness to how complex it is to build what seems like a simple idea to him, or on the flip side, perhaps the developer is over thinking the clients requirements, and the client will explain why he/she feels it's a simple task. This commication level is what I think is the greatest asset to Agile, and I think it's worth a shot to try out. I cannot see how this approach could not work well, although actually getting the client in on something like this could be a challenge.


In conclusion, I had a lot of fun today, from playin' with lego, to playin' planning poker, and just generally getting to talk with other developers from other companies, it was well worth my time there, and I'd go again in a heart beat.

This event was well worth it, and I will definately be back next year to attend. I'd just like to take the time to thank all the presenters for their wonderful presentations, my only regret is that I wasn't able to attend all the presentations, as I'm sure the ones I had to miss were just as interesting as the ones I attended. Posted on Wednesday, October 14, 2009 7:55 PM | Back to top

Comments on this post: SDEC09 - Summary of Lessons Learned

No comments posted yet.
Your comment:
 (will show your gravatar)

Copyright © Mitchell Lee | Powered by: