On Nov 5, 2010, at 12:42 PM, lprefonta...@softaddicts.ca wrote: > That's why the large consulting organizations typically fail...
I agree with most of your points. So let me address the one point which was the original subject of the thread... >> The primary point I was making was that each new technology introduces >> overhead >> in development, maintenance and operations. Therefore it should be included >> only >> if the benefit is compelling when compared to the change in costs associated >> with >> a team who can develop, maintain and operate a system that uses the >> technology. > > Exactly what I have been saying earlier in this thread. Pick the proper > tool... > if a project was developed faster with it then guess what, the maintenance > cost > will be following the same trend. I once had a very senior database developer take a set of requirements and deliver to me a solution that used a specialized database framework called Queues. Work was prepared, placed on the queue in the database, and a client later took the work off the queue and performed it. It took a few weeks to deliver the solution. It did everything it was supposed to do. But then the need changed slightly. We needed to resumbit work sometimes, or a portion of the work. We needed some work to be more important than other work. We wanted to tune the submission of work so we didn't pile up on a resource that was obviously not functional (e.g. a server that was straining or completely down). It turned out that for many reasons, the Queues framework was simply not designed to handle these variations on our original problem. After spending a lot of money and time trying to force the solution to work, we ended up throwing the whole thing away and using a simple table to store our work. Queues caused the product to be delivered perhaps 50% faster. But maintaining the product was a nightmare. Our database developer was a very senior resource. He had spent his entire career mastering the toolsets he used to deliver the product I asked from him. But it took all the cleverness of this senior resource to create a solution. The rest of my team were not as versed in that database platform and its frameworks as this developer. We did not have enough cleverness on the team to maintain the very clever tool he had created. This is why the proliferation of toolsets, including languages and major frameworks, is at best a necessary evil. Additional technologies add overhead and they add risk. This is why people want to keep the technology stack short and sweet. This is why speed of development does not trump everything else, and why speed of delivery is not a perfect corollary to ease of maintenance or operation. steven -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
