* Con: Developers have tendency to abuse new and “cool” technology in an attempt to show off. Unreadable or unmaintainable code is a problem whatever language it is written in.

This is still valid.

* Pro: Scala can reuse existing libraries from the java world. This should improve efficiency, especially if there is existing knowledge of Scala libraries in-house.

This is not as easy as the marketeers wants us to think. Actions have been taken in scala 2.8 to remedy most of this, though. I still haven’t written any significant volume of 2.8 code, so I don’t know how well the new java/scala integration works.

* Con: There is very little knowledge about what bugs may be caused when using Scala with these old libraries. This, sadly, is a also developer-dependent. The organizations that are already using Scala will have solved their own teething troubles – but this does not mean your organizations will not create the same kinds of problems.

Still valid. I would suggest seeking others who have experience. There is no need to experience issues that have been solved by others.

* Con: The development tools available for Scala are horrible. The best one while I am writing this is IntelliJ, with Eclipse in second place. I don’t like the compilation model of IntelliJ, so I am sticking to Eclipse. Netbeans is not a contender until the Oracle noise has been resolved.

This is still valid, but the Eclipse plugin for scala 2.8 nightly build started becoming usable some weeks back.

There are incompatibilities with other Eclipse plugins. In particular, I have experienced problems using the m2clipse maven integration. I had to reinstall the system from scratch to get the scala plugin up and running again.

* Con: Scala might not make it. What happens if Scala turns out to be a fringe language in two years? The risk of having to do another rewrite in another language should be factored into the decision to move to Scala. Personally, I believe in Scala, but there are no guarantees.

This looks more and more unlikely. I now believe enough in scala that I have accepted a position managing a group of developers who have chosen to use scala.

I now need the time to figure out how scala works at a detailed level. If anyone has a bag of time I could use, it would be greatly appreciated.

and it seems to be somewhat less than trivial to retrofit these parts of Spring to Scala.

Actually, I tell a lie. As usual with spring, it is just a question of who creates what.

I tried to wire something into a lift snippet. These are classes (Didn’t think. I would have made them objects since I don’t want one for every page view, but that is me. They are classes, and I didn’t catch that because I thought I knew what I was reading.)

So – I added a <context:component-scan> element to my application context. I then made a small change to my snippet, called AuthorOps:


@Component("authorops")
object AuthorOps {
var hibernateTemplate : HibernateTemplate = _;
@Resource{ val name="hibernateTemplate"}
def setHibernateTemplate(ms:HibernateTemplate) = { this.hibernateTemplate = ms}
}
class AuthorOps {
def list (xhtml : NodeSeq) : NodeSeq = {
val temp = AuthorOps.hibernateTemplate.findByNamedQuery("findAllAuthors")
(...)


And all of a sudden, the wiring works. Lift can create as many instances of the class as it likes, while Spring gets to wire the object.

Admittedly, this is a bit of a hack, but at least I managed to get spring to hook into some scala code. Hooray.

Now, I wonder if I can do the same to the transaction support…

I think you are missing the point in these ads, or rather putting more meaning into the wording than intended.

Um, actually, no. I am working it “from the other side”, as it were. I see what effects these kinds of ads have on developer teams, and they are not nice.

I have had someone who calls himself an architect tell me he didn´t care about costs, straight to my face. I think that is a horrible statement, but this guy isn´t an idiot. He has to have gotten his misconceptions from somewhere.

I think he had a long hard look at what would gain him promotion – or at least what people seemed to say would gain him promotion – and adjusted his sights to fit that goal. He is walking in the wrong direction, but I don´t think that is his fault.

I have seen this kind of miscommunication in various situations lately. Something must be getting through in the wrong way from whoever is setting the direction. We agree on what they are trying to do. I just don´t think it is working. If it isn´t working, they need to send different signals.

This is important. 90% of software projects come in over budget. The industry needs all the help it can get to get this sorted out, and to weed out any thoughts that money isn´t important. IT is a tool to make more money, not a tool to get rid of it.

Geir

I think you are missing the point in these ads, or rather putting more meaning into the wording than intended. I am quite sure that companies advertising in this way acutally want to ensure that they find people with eperience in running such large/expensive projects because they realize that it is important to keep track of the economics – a budget overrun of 1% sound very little, but when it is 1% of nine digits it is still a very large amount of money. I would also think that putting a person who only has run small projects in charge of a nine-digit one may be a quick way to ruin a good project and a good project manager all at once.

Having experience is important, and should be built up gradually. If a company needs someone to step into a position where a certain kind of experience is important they must either look at building up their existing employees gradually, or hire someone who can document that they can do the job. I doubt that they are trying to say “we are loaded with money and want to spend it fast”, but perhaps “we are loaded with money and want to spend it in the right way”.

Chris (Only up to eight digits in my projects)

I have mused a little about this on [http://dearjunior.blogspot.com/2009/07/not-enforcing-architecture.html] about the impossibility to enforce architecture.

Good post. Me like.

In your post, you write about taking the consequences. What consequences do you usually hang over the heads of your teams? Isn’t this despotism with silk gloves on? “Please do as I say, or else”?

An even harder question: What do you do if the team doesn’t do the right thing, the consequences consequentialize upon the team who then shrugs it off, and you still don’t have a solution? Bigger consequences?

I think one issue with the traditional architect role is that it has both too much and too little power. The traditional role tries to mingle both a kind of product owner-ish role with a coach/scrummaster function. I think it is excessively hard to get these two kinds of powers to flow nicely in one function.

To make it worse, a traditional architect has very little power over a team. The product owner proper has real power through the budget he controls. The scrummaster usually has at least some power over the composition of his team. An architect has neither. This sounds to me like a receipt for failure.

Seems I am full circle. Need to go another way.

Nonfunctional requirements and “cross-team issues” are no different from other requirements. These should also be on the product backlog if they have a value and a cost.

Some nonfunctional requirements may not be on the product owner’s radar, and it may be good to have people on the team who have this perspective when the backlog is being written.

However, like you talk about, the most effective way of being an architect is to guide the whole team to think about the right questions, rather than to give the solution.

We agree – mostly. I think there is a very good separation of roles between the product owner and the scrummaster. The project owner gives the “what”, the scrummaster can make it happen, often by doing architecty-like stuff.

Traditional architects are a bit different. They are usually also requirement originators for nonfunctional stuff. I think it is extremely easy to muddy the waters because of this. A nice workaround is to try to get the product owner to also give the nonfunctional requirements, but that takes a whole lot of effort for non-technical product owners, and I can see that some product owners would think I should just go away and get it sorted myself.

I also see teams struggling to get cross-team architectural issues sorted, especially when they try to work with non-agile teams, or with product vendors.

I am not even sure I want to give the title “architect” to someone in particular. I am leaning towards some kind of cross-cutting team where you carefully remove all the agile words and give them a list of deliverables to get sorted out, where you try to use the language that is common across the teams, and where the managerial meetings are cut to the bone.

I guess they would need some kind of project manager/scrum master. We may agree after all.

Maybe it is better to think of this as a Scrum Master duty. The Scrum Master challenges the team to think about their own process. Why not also challenge the team to think about the quality of their product?

Most of the architects I’ve met were also decent scrum masters and most of the scrum masters were either decent architects or at least aware of the questions they had to ask the team. Questions of architecture are appropriate at some retrospectives, and some retrospectives could be just about looking at the architecture.

Having tried both, I’d much rather be a ScrumMaster/architect than an architect on a team that has someone else as the ScrumMaster. The overlap between the roles is too great to know when you need to step in and when you need step back to avoid getting in the way of each other.