Two of the chapters from Beautiful Code Alberto Savoia chapter Beautiful Tests and Simon Peyton Jones on concurrency are available in PDF form. Beautiful Tests covers most of the different kinds of tests and how to make changes to code to make it more testable and starts to cover creating and validating theories.
Speaking of tests, Scala, DSLs, Behavior Driven Development?, talks about how Java is poor at creating DSLs specifically compared to Scala. And what's the application? Behavior driven development in a Java project called beanSpec (which superficially looks similar to Instinct probably as they're both based on RSpec and using the same stack example). So you have this neat sort of convergence where people are looking at testing Java better in ways that are more declarative (functional even).
Making Java more functional is on the cards for Java 7 in, Will Java 7 be Beautiful?, it links to point free programming in Java and Haskell and how the new language proposals (closures) make Java 7 look a lot like Haskell with the suggestion that all Java 7 functions should be curried.
While the syntax is potentially getting more beautiful, the user interfaces are traditionally pretty poor in Java (even with OS X support) but even that is changing. I've been following Chet Haase's blog and recently Filthy Rich Clients was made available to purchase. It's all about improving the look and feel of Java and to finally approach the richness of native OS X and Windows applications. He even has some links about language proposals too, including bringing back line numbers. Some examples of their work are on the web site and on Roman Guy's blog which includes an entry called Beautiful Swing.
Roman also linked to a movie of *7 the prototype handheld device running Green (Java). Who knew Duke had a house?
Showing posts with label behaviour. Show all posts
Showing posts with label behaviour. Show all posts
Wednesday, September 19, 2007
Sunday, July 02, 2006
Project Constraints
Ages ago in "Code and other Laws of Cyberspace" the idea of "The New Chicago" is mentioned. It says that behaviour is regulated by four things: the market, the law, social norms and architecture (or nature, the world you are in). In the original context it is described as a way that behaviour is limited in cyberspace and society and that the law can effect the other three to cause indirect behavourial change.
It seems equally appropriate in the context of a project. There are ideas that you can apply in a project that are (or at least should be) constrained in the same ways: laws, markets, social norms and architecture. In a project each constraint does not seem to have an equal effect on the smooth running of a project (they certainly could of course).
Laws don't usually have an impact on the constraints of a project. While people may break the law during the project or whatever and may have to go to court, get arrested, etc. the impact, at least in the projects I've been in, are quite minimal. They may effect certain requirements on the project (compliance to certain laws for instance) but generally they are well known or least able to be handled in a fairly straight-forward manner. No one generally argues whether a certain law should be abided by and usually people are available to ensure that the laws are readily adhered to.
Similarly, market forces have only a few effects on project cohesion as many decisions are already made for you - language, operating system and other infrastructural decisions are not usually up for grabs in a project. While some people may wish to do C# on Linux or Ruby instead of Java most people and projects limit scope in this way and resources are usually selected (or self-selected) on this basis. You don't usually find a .NET programmer amongst 10 Java programmers trying to convince them that Microsoft is the way to go.
The two key areas that do seem up for grabs and do cause problems are with norms and architecture.
The type of teams really dictate the level at which these two things can change and the methodology you use to achieve it. A well run XP project seems to allow a more participatory effect (mainly through pairing and pair swapping). If new ideas are accepted and tried then overall the team seems to have more of say. Certainly, the norms imposed on individual developers seems much higher in an XP project.
The opposite effect, somewhat of a project anti-pattern, is where a developer (or worse more than one) will go off and find a proposed solution and try to apply it to the entire project using a different norm or architecture. The rest of the team, quite rightly, does not feel ownership of the new technique or code. The effect of this is the opposite of what XP is trying to achieve - code ownership and cohesion. The key pushback to this is that no code goes into the project unless it has been paired on. If it is a project that does require a lot of investigation then each member of the team should get the ability to devise a solution to be considered.
There is of course limits placed on any project to change - moving languages or paradigms (OO, procedural, functional, etc) that XP has to abide by too. But in some ways XP seems much more honest (or from some perspectives limited) especially considering the "Extreme Programming Bill of Rights" where these kinds of changes will effect estimates, quality and progress.
It seems equally appropriate in the context of a project. There are ideas that you can apply in a project that are (or at least should be) constrained in the same ways: laws, markets, social norms and architecture. In a project each constraint does not seem to have an equal effect on the smooth running of a project (they certainly could of course).
Laws don't usually have an impact on the constraints of a project. While people may break the law during the project or whatever and may have to go to court, get arrested, etc. the impact, at least in the projects I've been in, are quite minimal. They may effect certain requirements on the project (compliance to certain laws for instance) but generally they are well known or least able to be handled in a fairly straight-forward manner. No one generally argues whether a certain law should be abided by and usually people are available to ensure that the laws are readily adhered to.
Similarly, market forces have only a few effects on project cohesion as many decisions are already made for you - language, operating system and other infrastructural decisions are not usually up for grabs in a project. While some people may wish to do C# on Linux or Ruby instead of Java most people and projects limit scope in this way and resources are usually selected (or self-selected) on this basis. You don't usually find a .NET programmer amongst 10 Java programmers trying to convince them that Microsoft is the way to go.
The two key areas that do seem up for grabs and do cause problems are with norms and architecture.
The type of teams really dictate the level at which these two things can change and the methodology you use to achieve it. A well run XP project seems to allow a more participatory effect (mainly through pairing and pair swapping). If new ideas are accepted and tried then overall the team seems to have more of say. Certainly, the norms imposed on individual developers seems much higher in an XP project.
The opposite effect, somewhat of a project anti-pattern, is where a developer (or worse more than one) will go off and find a proposed solution and try to apply it to the entire project using a different norm or architecture. The rest of the team, quite rightly, does not feel ownership of the new technique or code. The effect of this is the opposite of what XP is trying to achieve - code ownership and cohesion. The key pushback to this is that no code goes into the project unless it has been paired on. If it is a project that does require a lot of investigation then each member of the team should get the ability to devise a solution to be considered.
There is of course limits placed on any project to change - moving languages or paradigms (OO, procedural, functional, etc) that XP has to abide by too. But in some ways XP seems much more honest (or from some perspectives limited) especially considering the "Extreme Programming Bill of Rights" where these kinds of changes will effect estimates, quality and progress.
Subscribe to:
Posts (Atom)