A Curious Mind
#tastic

Being the Architect and YAGNI

Sunday, January 27, 2008 1:47 PM

So, I continue to find ways to be an agile architect. I just finished getting two teams started on a rather large project at work. For about a month or so ahead of time I was spending 2-3 hours a day ramping up on various technologies that I had been researching for use on this project. I had read books, discussed concepts with colluegues, and of course pounded out some code. :)

Well I got the team started, and I found myself getting frustrated with the teams. They just didn't get it, it was so clear to me. Then it kinda hit me. I had spent about 60 hours (2 work weeks) learning about this and they didn't get it on the first day or two. Gee, I wonder why. So, now I am trying to figure out how to best communicate this knowledge in the fastest way possible.

Any ideas?

The best idea I have right now is to communicate the various concerns I have identified in the system. I have a pretty good idea of how I would implement it but at this point its all half implemented code. I think it is going to be a better project if I back off of the code and let them find ways to handle the various concerns. To be fair I am forcing some new tools on them, and hope they make the work easier and not harder, but only time will show that to be true.

In closing, a big thanks to my team at the bank, and keep calling YAGNI on me, I am an architect after all. :)


Feedback

# re: Being the Architect and YAGNI

Yes, once we understand the core concepts and ideas, I think we will buy into them a lot better. :D 1/27/2008 7:28 PM | Robz

# re: Being the Architect and YAGNI

The best way is to pair up and code. There are quite a few folks in the Agile community who would consider a non-coding architect to be more hindrance than help. I know I lean in that direction.

Whiteboard discussions that dig into the details of the tech and architecture choices help, but a lot of times programmers aren't going to "get it" until they can see it happening in the code.

I know for myself, with the team I work on, it is not enough to say to them, "we should implement this thing in this way" or "we should use this tool." They want to know why, and often the why can't be expressed as well through speech or whiteboard as it can with code.

I don't know what your responsibilities are Dru, so it's difficult for me to say how much pairing/coding time you could reasonably expect to give to the team during this period of time, but my advice would be to do the opposite of what you're suggesting (backing off). I'd say do the opposite: get your hands dirty with them, so you can be there to answer their questions directly, and so you can feel the pain/pleasure of the technologies, tools and choices you've directed them toward.

When they see things click together in code and the light bulb goes on, then you can think about backing off, because the team will understand the bigger picture (as you do) and you'll know going forward that they're going to do things the right way, and not fight the technology or architecture.

The last thing you want is for your team to resist the tools/techniques because you've said "do this" and then "backed off" into your architecture hole. 1/27/2008 7:32 PM | Chris Holmes

# re: Being the Architect and YAGNI

Hey Chris,

It strikes me that I may not have best described my behavior. I am all about getting into the nitty gritty with my team, I guess I was just trying to spend some time reflecting on my goals. But, that doesn't make anything you said less correct. Thank you for taking the time to comment and I will rethink my whole backoff comment. Thanks! :)
-d 1/27/2008 7:37 PM | dru

# re: Being the Architect and YAGNI

Code Reviews, Code Reviews, Code Reviews..

I've been told that if the first one is a blood bath, the rest of the project will go a *lot* smoother.. 1/29/2008 11:34 PM | Evan

Post a comment





 

Please add 8 and 7 and type the answer here: