You can have a look at it …but use firefox as the web site has some display problems on IE (or maybe this is due to my IE configuration).
Finaly the famous Rails framework enter in java world, that should provide excellent reasons to no more see this RubyOnRails video:
[youtube:http://www.youtube.com/watch?v=PQbuyKUaKFo]
…SF as Software Factory, I mean a full featured development infrastructure. This became obvious to me when I read the post of Ayende on his vision of entreprise platform.
Ayende had the idea to base the system on code versioning system. This is definitely a great idea that I share, but I think this should go beyond: a complete software delivery infrastructure. The customer (software providers in fact) should be able to build, test and deploy applications….services for others users.
The great idea to relly on a source control system will solve the problem as versioning of the applications (for a part of it) and when you have multiple developpers working on an application or service. But this does not fullfil all the requirement for a PaaS, what about tests & validation, deployment (especially for multi-tenancy), delivery, maintenance…etc.
Finally, the requirement is to provide to some users a full featured development and delivery environment. The excellent post on the Lack of good Paas platform is highlighting very well all these requirements: customization and configurability, versioning and multitenancy, security, scallability.
I would add a requirement on robustness: as soon as multiple users can deliver software on top of platform shared by all…there is a high risk to have the system out of control. Ensuring a high level of service is fundamental, so the system should be really robust. The challenge is to let the system open (the sw providers are building software - so very high level of freedom) and “a live”, but this will be the topic of another post.
What about Program and Development Management that are using a waterfall approach with agile development team? By waterfall approach for management I’m talking about management decision not to start the development before requirements are defined, planification and release date setup. It’s not unusual to see also a stabilization phase defined as for example the last couple of iteration.
This is mainly due to:
The final result of this approach is that the development team is not working at all…because it’s simply forbidden. The market driven approach has been well understood by Product Management and they are blocking any kind of development before they have decided what features have to be implemented.
Joaquim Rendeiro talk about co-existence of waterfall (especially for management) and agile methodology in his post on Agile or Waterfall?. Yes, they can exist but may have the consequences I’ve talked about.
IMHO, this occurs inside teams that are transitioning to agility and are not mature enough on this agile approach. As agility provide a huge responsibility and control capability to the product management, they used this extra-strength keeping in mind the waterfall approach targeting dates and content of the releases.
The development management should be the driver to accelerate the transition to a real agile approach. For example by rejecting all big kick-off meetings to start a release, and encourage a better preparation of each iteration. The development team managers should also avoid any technical discussion include an product owner and take the responsibility to make the technical choices. Often, the technical choices are delegated to product owner. Yes this is strange, but haven’t you any discussion with a product owner like: we can implement the story this way and it will cost 13 points or a different way and it will cost 21 points but this last one is less good for reasons A and B. Let guess the answer…do the shortest path. Even if this is usually the good answer from a technical perspective (I’m supporting the principle of simple design which is often shorter to implement), there is not reason to delegate this decision to product owner.
Agile approach requires a clear definition and separation of responsibility for every shareholder.
Getting agile is probably the only (or best) way for large R&D organization in a software company to setup their workforce in front of their need. They usually are working over multiple products (legacy or not), and are market driven. In small software companies, the product management marketing function is endorsed by R&D management and they work usually on a small number of projects which are at least tightly integrated, which means R&D team is focusing on only 1 common goal.
Start-up have focused/sharp vision, excellent creativity. Large company are relying on strong market analysis and capacity to move on…most of the time as soon as a startup has demonstrated new markets. Vijay Challa talk about this in his post on Agility World 2.0.So, they have to invest (put development resources) on the products depending on the market trends, profits from each product,…etc. That’s why its important to be able to switch developers from a product to another to be reactive.
Some agile principles helps for this:
I tend to think that agility is maybe not always that relevant for small company, but its certainly a must have for large software company to be reactive.
Agile methodology are based on the capacity to make the code evolving. Extrem Programing have some principles around that as simple design and continuous refactoring for example. Notice, that the aim is not to anticipate future evolution.
Even out of an agile perspective, this is a good practice to keep code simple, maintainable, easy to make evolve and avoid what I call the Critical Code Mass. This post of Kevin Barnes on The Code Garden is worth to be read and is also talking about code evolution capability.
All this is about complexity of code, but this does not means thousands or millions lines of code. Of course, having a very tricky algorithm written with a too large code base will create difficulties when an update will have to be done: a new developer will need time to explore this code before doing the change (maybe even do some prototypes). Even the author himself of the code maybe request additional time to test the change before checking in.
The Critical Code Mass can also be achieved on a very small code base, for example, when the algorithm have kind of magic: few lines of code, but it is not obvious how it work and even why it is working. Implementing a change can also be a challenge.
I think it is really important to take care of this Critical Code Mass if you do not want to let your program behave like a black whole. This evolution of the code is silent and do not appear suddenly. If all the development team is not aware of this and do not pay attention to avoid it, the projects evolutions will become more and more difficult and long.
I’m using Rhino Mocks and I’ve seen the real great feature “Ability to joke” when this (click on the image to see it as my theme does not have a main column large enough):
Finally my test was just wrongly written. I’m using RhinoMock and I’m very pleased with it, so I was really surprised by such message.
Ayende, don’t ask the step to reproduce of this, I’m not able to reproduce it and I did not backup my program at that time…sorry about that. The only think I can tell is that I was playing with 2 threads in this test…and the test was not testing what it was supposed to.
My recent post on BDD was a little bit light and requires some deeper thoughts.
BDD versus TDD is part of hot topics that introduce too much pation too often…so I will bring my 2 cents.
The video that I mention is the post raise key points to my mind about BDD vs TDD:
Finally, I don’t think they should be opposed, and the pasion around this topics seams, to me, due to mis-understanding about the wording. What is sure, is that they can be used to express the validation of some code before writing it.
They are not incompatible: you can validate a controller for example using TDD or BDD. The test won’t be the same, they will introduce/guide different code to the end…but both will validate that the code works as it is suppose to. Some will rightly argue that you will use Mocks if your controller interact with a class that send SMS for example, and you do not want to pay for the SMSs that you are sending during your test. But using Mocks does not meant your are doing BDD: you can use stub and validate the state of the stub instead of the call to the Mocks.
I think most of the discussions are to some extend steril as both approach are usually both valide. Nevertheless, I found this video very interesting on the rational behind TDD (or BDD) and where it goes. I personnaly dislike the idea of 1 class = 1 test class (same for methods). I think that the grain and organization should be different. The validation that makes sense, is to validate a feature that represent added value for the end-users. This is were is the true BDD. To me BDD just extends TDD (as “test first”) by making the relation between code and feature. Decoupling code and feature is the best way to get better tests as they are close to the features. When I say better, I mean easier to maintain, breaking only when one feature breaks.
I recommend 2 great articles on this topic:
Management tries to dertermine a magic number between ideal days and real days. The rational is always the same: PTO, meetings, illness…etc.
But, even if an ideal developper would exists (never ill, no PTO and no meetings) there will always be some shift between estimates and time to developpe the feature. I see at least one reason which has a significant impact IMHO: he is not working alone! He will have to synchronize with the source control before check-in. This can be done efficiently if the SCM system is efficient and longer if not…or if there is no SCM system. The result of this synchronization is absolutely unpredictable.
Maybe, the “single brain” (a team of…1) is the right approach to get accurate estimates…but it has its own drawbacks.
The best is probably experience.
Another step before check-in which may be longer than expected is the refactoring.
Take the time to look at this vidéo, it’s one hour long, but worth it.
Agile methodology are far less adopted than traditional waterfall methodology. Is it due to a lack of maturity? Maybe yes. I think Agile methodology will continue to evolve and this is a good thing.
I think that agile methodology are misused and people is emphasing too much the test versus design which is not to me the original sense. The ‘behaviour’ is really the unit of mesure of the business value provided by a software.