+972 52-548-6969
What are you in for?
There is a level of tension between what a developer wants and what the client wants. As a developer, I want to use the coolest technologies, the freshest methodologies, to be so far on the bleeding edge that they have an ER dedicated just for my team.
As a client? I want to be as conservative as possible, for the most part, I don’t care for new technologies unless they have some significant feature that I can’t get anywhere else. I value speed of development over having the devs geek out.
I spoke about before, the tendency of developers to start building castles in the sky in favor of getting things done. I call it Stealing From Your Client, because you are introducing additional things that aren’t necessary, won’t bring additional value or just plain make things hard.
For example, in just about any project that I have seen, putting an IRepository in front of an OR/M or putting an IRepository in front of RavenDB was a mistake. It created no value and actually made things harder to use.
Other pet peeves of mine was raised in a discussion about architecture in a recent lecture that I gave. One of the participants asked me for my opinion about CQRS. But when I asked him for what sort of an application, he answer was somewhere along the lines of: “I want to build my next application using CQRS and I like to hear your opinion.”
This sort of thinking drives me bananas. (Editor note: That sounds like a very painful thing, and I am not sure why I would do that, but it appears that this is an English expression that fit this location in the post).
Dictating the architecture of an application, before you even have an application? Hell, making any decisions about the application (including what technologies to use) before you actually have a good idea about what is going on is a Big No! No!
Here is the most important piece of this post. For the most part, all those cool technologies that you hear about? They aren’t relevant for your scenario. And even if you are convinced that they are a perfect fit, there is a cost associated with them, which you have to consider before attempting them. Especially if this is the first time that you are using something.
The really annoying part? Most people who come up with these exciting new technologies spent an inordinate amount of their time saying not how to build apps using them, but when you shouldn’t. Evans’ DDD book quite explicitly state that DDD shouldn’t be your default architecture, that it has a cost and should be carefully considered. The industry as a whole (me included) just ignored him and started to write DDD applications.
Greg Young just lectured in Oredev about why you shouldn’t use CQRS. For much the same reason.
At the end, we are there to provide value to the customer. Yes, it is cool to work on the newest thing on the block, but that is why you have hobby projects.
Comments
RavenDB seems to fall in the middle of those 2 scenarios. Cool new technology, but makes development got a lot faster with less friction.
The only issue I've seen is that large companies have huge infrastructures setup for doing deploys, maintenance, etc, and Oracle or possibly SQL Server are allowed. It'll be a good day when companies start having Raven-DBA's on staff. :)
Very nice post as always. I think that sometimes it has to do with the project scope. The project must have a very well defined scope and you have to stick with it until the end. I find this very hard, so I usually tend to over-engineer my projects, loosing track of the project scope.
As you noted the client and the developer don't share the same concerns. The client just want to know when it is ready and how much it is going to cost. The developer has to think where he wants the project to go and assess if the current design can cope with the future changes and what can improve the development speed.
Last year I was working on a web project where I wanted to add a much better user experience. With jQuery and jQuery UI alone, the client side development was taking too long and was quite repetitive. I then heard about jsKnockout and how easy it was to add new UI behaviour. There was a small learning curve but I still do believe it was worth it.
Now, as you said, adding a new technology without knowing if the user will benefit from it in the long term it is obviously not very wise.
As you noted the client and the developer don't share the same concerns. The client just want to know when it is ready and how much it is going to cost. The developer has to think where he wants the project to go and assess if the current design can cope with the future changes and what can improve the development speed.
Last year I was working on a web project where I wanted to add a much better user experience. With jQuery and jQuery UI alone, the client side development was taking too long and was quite repetitive. I then heard about jsKnockout and how easy it was to add new UI behaviour. There was a small learning curve but I still do believe it was worth it.
Now, as you said, adding a new technology without knowing if the user will benefit from it in the long term is obviously not very wise.
I find to get talented developers you have to take the age of the technology into account. No one wants to work in a tech that won't be in high demand a year from now. This might be a circular problem: we go for the latest technology to attract developers, and developers are constantly looking to learn new technology to stay competitive in the market.
IMO there has to be a strong balance between the two. You can't jump on the bandwagon for every new thing that comes down the pipe, but any sane business with longterm plans (as opposed to a fly-by-night, get rich quick scam business) needs to have SOME kind of upgrade plan to avoid being left behind. Nobody wants to come and work for a company stuck in the dark ages with zero plans to move forward.
Take my current job for instance. We are using .NET 3.5 in theory but it's all legacy junk from the 1.1/2.0 days. No ORM. No design patterns. No architecture. Just a collection of web pages with some classes that return DataSets filled via Stored Procedures. The code is a complete mess, and even beginning to refactor parts of the app to even attempt to use things like tests, to say nothing of an ORM or ASP.NET MVC, is a herculean effort in and of itself. Yet management remains totally clueless as to why this is a good thing and even goes far enough to forbid us to make these refactorings as it would take away from "adding value" (read: adding useless features that are just eye candy and marketing buzzwords).
A place like this is in a perpetual downward spiral as you can't easily improve things to even an average standard, but because of that it's insanely hard to find and retain good developers as nobody wants to be stuck writing stored procedures and dealing with raw untyped DataSets in 2012 when there are better alternatives that have been in wide use for half a decade now.
Wayne I feel for you. Being told not to write tests is probably the most infuriating thing a developer can hear.
It's not even so much that, it's the fact everything is so tightly coupled that even getting to the point where we could write tests is at least six months or more of work. Practically every single class in the application would have to be redone or heavily refactored (which would in turn hit every other class) to even support testing because it's a mess of copy/paste code (seriously, I once counted four different classes in a particular area that each had almost the same methods/properties, copied and pasted from each other, and each class was used in a different part of the application).
The worst part of all is that management doesn't see this as a problem, but they do see wanting to freeze development to fix things as a big no no.
from Greg Young's Blog http://goodenoughsoftware.net/2012/03/02/cqrs/
CQRS
CQRS is not a silver bullet CQRS is not a top level architecture CQRS is not new CQRS is not shiny CQRS will not make your jump shot any better CQRS is not intrinsically linked to DDD CQRS is not Event Sourcing CQRS does not require a message bus CQRS is not a guiding principle / CQS is CQRS is not a good wife CQRS is learnable in 5 minutes
CQRS is a small tactical pattern
CQRS can open many doors.
And yes you can support RFC 2549 using CQRS
Comment preview