This is a very big and complex problem, so I can give a few notes.
First, I don't think the application of a vertical or horizontal slicing does not effect the unit testing so much. Why? A unit is a unit. It is not a whole layer or a vertical "story", but a smaller unit of development and isolation. Normally, the author of the unit develops the unit test set for it, but it's very important that this test could be reviewed and updated by others: one person, especially the original authors often have some vision they are preoccupied with, and this limited vision often prevent then from seeing problems or concerns apparent to some people of fresh glance.
Now, about the vertical vs. horizontal splicing. There is a good number of Agile absolutists who bring very strong arguments in favor of vertical slicing, at least in their opinion. See for example:
http://www.cincomsmalltalk.com/userblogs/buck/blogView?entry=3311184808[
^],
http://agilewarrior.wordpress.com/2009/07/27/horizontal-vs-vertical-slicing/[
^].
Here is the thing: I saw so many books and articles on the software development methods, some are written by people of big well-known names; and I never saw one which would make me too enthusiastic about arming myself with a method's techniques. Don't get me wrong: I am not against the method and not against methodology. It's just everything looks to me not like a real science but rather like some blah-blahology, so to speak. At the same time, some methods and books reflect real experience, positive or negative. So, I would say I would advise some hybrid approaches, hard to say how exactly. It's better to say, not that they should be hybrid, they should be project-driven, that is, the method should be built and adjusted in place of work, depending on many different factors: major project goals, resources, available code and technologies, and, very importantly, people involved.
Speaking of the "unbreakable" arguments in favor of strong vertical approach, I can always point out some serious drawbacks. The layer is shaped by the whole team? But then, who would be responsible for its integrity, elegance, unified architecture and design? Development of a layer is performed incrementally and constantly? This is good, but who will prevent the erosion of it? The layer will be free from all the bells and whistles, that is, redundant features? But how the new features can be implemented? One by one? Then you risk to fall into ad-hoc style, effectively preventing reuse of the code or stimulating erosion of commonly used utilities or algorithms. So, my conclusion is: some hybrid approach is the most prudent, but the location and degree of hybridization should be envisioned based on the project specifics and adjusted interactively during development. Isn't this the same interactive approach so valued by the strong Agile proponents? I think I was using Agile elements well before the term "Agile development" was coined, but the method was ever changing. And never perfect.
Now, I want to touch the role of the project leader. Even though Agile ideas promote distribution of the decision making among the team members; and this is the good trend, the process needs someone to uphold proper architecture, requirements to the code and development discipline, and this is not just keeping up with the formal procedures, otherwise the erosion of the project an unmanageable entropy build-up is unavoidable. Whatever method you invent, it has to be one person of a very small group of people; in my opinion, no more them two or three. Such person or a group should be able envision the future of the project and development process and foresee some of the fallacies. It takes a very cunning vision and experience. Such people cannot foresee everything, but they can do mistakes. The best leadership is not when the leaders make no mistake and keep others out of mistakes; this looks nearly impossible; no, the good leadership is when the mistakes are finally fixed, but the fixes are not so expensive to ruin the project.
And finally, I want to mention such a painful problem as the problem of a non-technical project managers (and sometimes even "architects"). I mean, non-technical or not doing enough work as a software developer. This is something which often happens, and this is a curse of all the software industry. The mechanism of it is quite understandable: people don't want to waste the time of talented developers for the management, so some worse or mediocre developers who just are too uncomfortable with creative development and technical decision making are "promoted" to the management. As a result, everyone suffers; nobody respect such people and resist, such managers block good decisions and promote lousy ones, create tension and also suffer from all of it. It goes even worse when such people gets too much initiative; it often creates disaster. I think many developers are well familiar with such settings but usually don't speak about it. It's really important that the knowledgeable people raise their voice to prevent such situations. This is not easy.
OK, why am I writing and writing? A whole essay… Let me round up here.
Thank you for reading,
—SA
Submit an article or tip