A couple of months ago on one of my trips to Redmond I met up with Ron Jacobs and recorded this ARCast.
As is typical with most things from Redmond it has taken time to ship but at last you can listen in to our conversation.
How much architecture is enough? I have been on both ends of this. I have seen projects where the architecture was endless filling 3 ring binders with documents that would probably never be read by anybody and I have also been on projects where each developer acted as their own architect and the result was a hodge-podge of functionality cobbled together in a way that was totally irrational. On this episode of ARCast – Dr. Neil Roodyn author of eXtreme .NET shares his perspective on getting the balance just right.
Subscribe to:
Post Comments (Atom)
4 comments:
The following is a email I sent to Ron:
Hi Ron,
Just emailing to say that I love the show and am really learning alot from it. I've been listening to your shows for the last couple of weeks but haven't got round to emailing you because I'm too busy listening to Arcast! Anyway I loved your show with Martin Foley and also Dr Neil.
I've just graduated from a Bachelor of Computer Science at Melbourne Uni
in Australia and so though I've got some knowledge about designing and
writing software, when it comes to architecture I'm a newbie.
Anyway over the last few months I've been learning a lot about Agile, TDD, XP and it's all really fun.
The thing is though, I started reading Code Complete 2 which says that you should design software down to the method level. Is that the same as architecting down to the method level, or does that mean the developer designs the classes and methods him/her self before implementing them? I'm interested in this because in your podcast with Dr. Neil he said that architecting methods is going a bit too far.
The other thing that I read in Code Complete 2, and which at the time I really believed 100%, was that you should design to more and more detail until it's easier to implement the design you've got than to create a more detailed design.
After listening to some .NET Rocks! podcasts and some DnrTV shows about TDD, Agile etc. I've totally changed my view about designing software to this level. All within a few months! I guess I'm easily convinced!
Anyway, on .NET Rocks! Richard made a comment allong the following lines:
"You've got to get the database right. Then you can hook up the stored procedures to the middle tier and then focus on the UI."
I think this comment was on the show about Subsonic, and Rob Coney (Ruby on Rails guy) actually agreed with Richard.
The thing is after Richard had made the comment and before Rob had agreed with it it I thought to myself that that was wrong.
The reason is Agile and TDD is about implementing a vertical slice of the
application as soon as possible
as Dr Neil said. But does this mean you are constantly re-modelling the
database?
Well in the video on the Ruby on Rails website (the one about creating a blog engine in 15 minutes) at http://www.rubyonrails.org/screencasts David Heinemeier Hansson creats the
database in stages.
Now I know that this is a small example, but this is what I think the idea of Agile development is about.
So if we had a framework in place for doing Agile database development (DB Unit Tests, DB Version Control and DB continuous integration) then maybe Richard is wrong.
The other interesting thing I found about your show with Dr Neil is that he talked about communication and everyone knowing about the overall architecture of the system.
In my case I'm working for a property valuation company who has an existing system in VB 1.1 and
want's do a total rewrite in C# 3.0. I'm the only developer! The whole IT
department is me, a consultant/architect working part-time and a system admin.
So in my case ( a guy straight out of Uni as the only developer starting from scratch) do you have any advice on how to make the project a success?
Sorry for the rant but it's all very exciting!
Regards,
Jonathan Parker.
Hi Jonathan,
some good thinking.
I have discussed these issues with Steve McConnell in the past and on some issues we agree to disagree. We do things differently.
Steve is Agile in the sense that as he learns he changes the design. The main difference between the way we think is how far ahead of time we _design_ the code.
I tend to do my desing much closer to the time I write the code than Steve. TDD helps with this, it allows me to design in a way which is more flexible. Sometimes I break this rule when I have to interface with a component being written by someone else. If I cant work closely with that developer then I would like to work out the interface before so we can both develop our components with a higher chance of them working together.
As for databases I disagree with Richard here. Databases can be refactored and changed as well as code. There are too many developers who believe every system starts with the database, in fact some systems are written starting with the database when the system doesn't even need a database at all!
My best advice is find someone to mentor and guide you. If the company cannot employ a full time senior developer then at least get someone in for a few hours every week (or 2) to ensure you are going in the right direction.
Developing software is a craft that is learned over time. Experienced developers who have shipped many products (and failed on some) will have a second sense for when things are not working. Mostly this is based on things they have experienced in previous projects.
best of luck
Dr. Neil
From my point of view, when you are in a solo development being both designer and developer how close to code you design is not as important as when you design for a team, where you have to explain yourself quite better.
I mean, you know what is in your head and it doesn't matter if you design too far or in too detail.
But I agree that the earlier you start feedbacking your design from coding failures and success the faster you will develop and the closer to coding time the better it becomes!
Cheers.
Post a Comment