People: Shannon, Aaron, Peter and Kim
This open space was intended to discuss the future project structure of umbraco, with regards to how we should divide and manage the development effort moving forward. The talks did however run into a set of more technical discussions, but in the spirit of the open space methodology, that was what was supposed to happen.
Dividing the development effort
Looking at umbraco today it is divided into a set of projects within the umbraco solution, but there is a very tight connection between the umbraco UI project and the data layer project, where today it seems that the data layer is only there to support the UI - most methods in the data layer are created as they appear relevant in the UI.
We talked about dividing the development effort in a more stringent way where the different projects are better separated. E.g. the data layer would be a separate project that would provide the business logic project with a set of data providers. And then the business logic project could expose a set of providers - e.g. document providers - to the umbraco UI project.
As mentioned we did talk about the current state of umbraco and it is easy to see that Niels has had some thoughts on this at an earlier stage, so we agreed that moving in this direction where the development of the separate projects are more autonomous could be a way moving forward.
With regards to dividing the overall umbraco project into smaller parts we did touch upon Large assemblies with lots of functionality vs. small very specific assemblies. We did not come up with a conclusion on that front.
Making the project more professionel
If running an assembly analyzer tool it won't display any information on who has made the assembly etc. This does not seem professional, so we had some talks about making the assemblies and code files more professional to other developers as well.
We agreed that we must sign the assemblies so other developers at least know where the code originated. Making the code look professional also covered talks about implementing at the top of every code file some info on the origins and license of the code. This could be done automatically upon the compile and release of a build and its associated files.
Starting with the specifications
As we in earlier sessions had discussed a lot about the next version of umbraco, and how this must include a rewrite of a lot of the codebase, we talked about how we in the development team make sure that we are all on the same page and agree on the goal.
We fairly agreed that we must begin writing a functional and technical specification. As most of the functionality that we have to create in the rewrites is already available in v4 the functional specification is of less importance than the technical specification, but both will be of importance to the development team.
Our talks ended by briefly touching on the subject of documentation. This is a point that must be prioritized along with the rewrite. Code comments will be of great importance, and as support for it is build into Visual Studio the following fields are a must: summary, params, returns, remarks, example (of use), exception. We could use Ghost Docs for autogeneration of documentation.
Up front design documentation was also discussed, and found important on more levels, to give an introduction to major functionalities. It is important though to keep this kind of documentation sync'd with the code, if it is to have any purpose for developers in the future.
Extensibility
With umbraco today it is possible to do a lot of stuff, but it is not a very extensible framework in the sense, that everything a lot of properties are private. This disables extensibility. Why not move to a model where properties are protected? This would promote extensibility. Another way to go is to make properties and methods protected and sealed to begin with. Then we can open the posibility to extend it at a later stage.
Testing
On the topic of testing we all agreed that automated testing is a must. We have to start writing Unit Tests or something equal, to be able to more qualitatively determine whether changes in the code have affected other parts of the system. These tests can be run upon building the code for release.
Exceptions
Exception handling and throwing custom exceptions was briefly discussed. Following the Microsoft guide lines is the way to go. Throw a custom exception if the exception thrown by the framework does not describe the error - e.g. a NullReferenceException should always be handled and must never be thrown.
The Log
Log - we do not like it, as it fills the database and there is no easy way to purge the log from within umbraco. A way to go in the future could be to use another external logging system. We could for example use Log for Net or another similar logging system, which provides much better configuration posibilities.