Boise’s first Open Spaces event was a raging success (IMHO). Thanks to Scott for organizing the event, and Jarod for guiding us through the (non) process. I hope that we can repeat the event soon with a wider audience and longer duration.
I sat in on 3 groups, the first as a full member and the last two as a bumblebee. Here are my rough notes from each session. Most of these are just the questions that we hashed through without the answers, I guess you had to be there for that.
- Domain Driven Domain
- Do you choose Repository or Active Record?
- Can a dynamic language give you the quick ramp up of Active Record and the long-term maintainability of Repository?
- How do Domain Specific Languages relate to DDD?
- What if you create a DSL to define your business rules?
- Do you choose Repository or Active Record?
- Teaching Object Relational Mapping to junior developers
- Which ORM do you choose?
-
- In the .NET world it seemed to boil down to a choice between
-
- NHibernate
- LINQ for SQL
- Castle Active Record (apparently built on top of NHibernate)
-
- Java
- Hibernate like mapping (EJB, JPA, etc…)
- Start the junior developer off learning the domain model and try to isolate them from the object-relational impedance through HSQL
- iBatis approach
- Expose them to the internals of the relational database and make the mapping to the domain process manual
- Hibernate like mapping (EJB, JPA, etc…)
- In the .NET world it seemed to boil down to a choice between
-
- Which ORM do you choose?
- Technical leaders moving into management
- Two different tracks that exist at a lot of companies
- Technical track
- Management track
- Both are intended to have similar pay and promotional opportunities
- At smaller companies, this dual track doesn’t always exist and technical people are forced into management to chase promotions
- As a technical leader (ie Architect) how do you stay “in the code enough” to make competent long-term technical decisions?
- Make sure your code is architected so you can recover from poor mistakes
- For example be able replace your persistence layer in 2 weeks, mitigating a poor persistence layer technology decision.
- Will your developers feel like you are the non-coding architect passing down edicts from above without knowing the details or impact?
- Make sure your code is architected so you can recover from poor mistakes
- Two different tracks that exist at a lot of companies
- The event closed with a great pissing match of who has worked on the largest system, I think Chris and Jarod tied for first place.
Technical and management skills don’t always have a lot in common; did that come up in the discussion at all? It’d be interesting to see some future blog entries from people who have made that switch, and from people who have managed to stay on a technical path and reach a level on par with more management-oriented directors/vice-presidents.