DevDays 2010 in Cape Town was slick. Very slick. You guys really know how to put an a good show.
Most of the speakers were good. Most demos were good. Most jokes were funny. The food was mostly good. The mood was mostly good too. And the fan club was mostly impressed. And most noobs were converted forever. And the new features were mostly so good, apparently, you won’t have to write so much code anymore. And the most underused word was design. Most absent words were TDD, refactoring, quality, and clean!!
I understand that DevDays is a product showcase but, come on, MS South Africa, at least cater for the entire spectrum of developers, just a little bit, and in a responsible manner. How about pitching content that shows that you do care about design, about clean code and quality. How pitching the new features in a way that shows a trend towards agility, to being able to refactor code continuously, to test first and other vital aspects of professional software development.
Let me give you just an example to illustrate what I mean. The EF4 code first demo was explained completely as if the classes in the model are no different from entities in a table. Even the language used was “entities” and “keys”. I don’t think I heard the word “class” or “object” once! You may have slides with the words “Code First Model”, but if you don’t actually do it for real, then you’re just leading dataset-happy developers that are marginally object-oriented further away from good code and good architecture. You need to explain why it’s better: that it promotes better object orientation, that POCO models disconnected from an ORM can be done test-first, and you can evolve your model, instead of designing up-front, blah, blah, blah.
Another time there was a ping-pong table with a developer at one end and tester at another with a bug being batted between them. That pulled quite a laugh from just about everyone. While that is reality in many organisations, there are many of us that test our own code and deal with our own bugs. The tester that we toss our code to is our automated continuous integration server. Tossing code downstream when it’s too late for reprise is not very professional. How about focusing on the testing tool, as opposed to pitching it in a manner that makes everyone believe that dealing with the bug downstream is just the way its meant to be.
Sure, I know that you need to show off the latest cool things and evangelise your products, but there is a sector of developers that you are blatantly ignoring. It is the sector that is, perhaps, the most influential amongst other developers. We are those developers that value our craft of software development. We evangelise the craft and the value that it brings to our lives, our teams, our projects, our clients and our organisations.
Perhaps I am just delusional.
Oh well, so long and thanks for the fish.
f3yourmind 
Let me give a second go!Firstly, thanks for the comments
We have been reasonably open about stating that Devdays is about keeping abreast on new technologies – and we even try to keep the work “best practices” out of the blurbs. I know some dev do this but I attended sessions myself and learnt some interesting things on reactive extensions for example.
Does that mean we do not care about good design, best practices etc. No, not at all. What happens though at times, is when you are explaining some new concept, it can be difficult to do this in a context of best practices, patterns, testability etc. Firstly, we are time constrained and secondly it assume that the audience understands those concepts. Recently, I attended an introductory session on Azure. The speaker that did the session used some pattern that I was not that aware of. As a result I got lost and did not get to learn Azure or the pattern. It is fair to say that at an event like Devdays, we tend to go with the lowest common denominator.
Does this mean that those concepts are not important. Not at all. They do have their place and we (and when I say we here I mean the community as well) need to focus on them. Whether Devdays is the best place is a point of debate. We will look to see whether we can perhaps incorporate another track to focus on this, but logistically a 4 track event can be difficult.
The other aspect to this, is that finding really knowledgable people who are also great presenters on these topics is ultra difficult. The overseas guys cost lots (we tried to get them to TechED) and there are not many local experts. As someone rightly indicated, you need people who are practising this daily. You also need people who can present to a broad audience (i.e present to people who might not understand the basic concepts).
I think Claudio’s comments on testing explains what we were trying to explain around the ping pong with testing. It had nothing to do with dev testing. it had to do with the typical workflow of a tester and dev. In an agile dev environment a tester can pickup a nightly build and the bug does not have to be caught downstream. Not all testing can be done by devs. Aslam – I think your comment on testing knowing how to code is a bit off. This is the way that MS does it (and the way you guys do it). However in our surveys of the market and in the sessions I do 70% of testers do not write any code. They do manual testing.
Ultimately, we are aware of the need for more developer practices sessions – and we are more than happy to engage with anyone on the best way to accomplish this. Feel free to use the blogs.msdn.com/southafrica contact us link to send us your feedback, and your willingness to participate.
No testers? In my teams, even if developers test their own code, use continuous integration, TDD, BDD, etc., the role of testers is still relevant.Testers, however, are first-class citizens in the team, they are involved in all phases and simply don’t waste time on things that developers should catch in the first place.
Despite these differences, I’m confident that the nature of the collaboration is completely different from the one in the example you mentioned above 😀
Aslam, I completely share your frustration. The current trend, particularly in vendor-driven conferences, is to have flashy (should I say Silverlighty? :D) presentations about a product/technology with very little attention to design or proper practices.
Perhaps the reason is that it takes a kind of practical experience and care for the craft that most evangelists simply don’t have. And this creates a vicious circle as the community, at large, grows unaware of what is possible.
At the end of a product pitch, I routinely ask presenters: “How do I design testable/maintainable software on top of this technology?”.
Judging from what I see and hear, I often have the sad feeling that they haven’t heard that before 😦
Hi Claudio,
Yes, the context for the tester comment was different. I think we both view testers as people that do know how to code. I’ve stopped categorizing them differently because of historical stigma. The key is still that the testers check in tests that are executed by the continuous integration server. What I saw, did show collaboration but the point of the blog post is that MS have a responsibility, at these events, to promote good practices. Sadly, I got the impression that the practice itself was not even understood otherwise it would have been a perfect backdrop for the features being demo’ed.
Well said Aslam.
Events like DevDays present a unique opportunity to reach developers that can’t be reached otherwise. Instead of just spoon feeding these developers the latest and greatest from devdiv, at least nudge them in the right direction by referring to good practices in the presentations.
I’ve heard Microsoft guys say that DevDays really isn’t aimed at the more experienced developers. I think Microsoft *should* aim a little higher, and maybe this will have the effect of those developers leaving with a feeling of “wow, there are better ways to do things, and I need to investigate some of these concepts for myself.”
In other words, interact with these developers as if they are into TDD/clean code/good design, and pretty soon, they may just be!
There are brilliant developers (even some Alt.Net guys) at MS DevDiv that espouse these principles, and I see them regularly interact with some of the best developer brains in the world. I’d like to see their employer openly engage developers of all levels on these principles too, even if they do it while selling their shiny new products…
Hey Janco,
Exactly! You can have shiny new products and cool things and still promote good practices. I also know that a few people in MS abroad that do practice what I am rambling about. Perhaps it’s still in the minority, but it does exist. And the alt.net folk do influence, but the only reason alt.net exists is because of the delusion.
[…] This post was mentioned on Twitter by JanVanRyswyck, Aslam Khan. Aslam Khan said: Just blogged my thoughts on MS #devdays. Delusion: A firm belief despite contradiction in the face of reality. http://bit.ly/bAqmjg§ […]
Please fix the commenting so it does not lose my data. I made a long comment but since I left out email, it lost it all. Need to run off now
This is exactly why I didn’t petition my manager to let me go to DevDays.
For the people that do not follow blogs/twitter, I’m sure they learnt a lot and saw some nice things. Those are probably the people that are going to go back to work, rave about what they saw for a week and then forget about it all.
I would much rather go to a targeted conference and learn about in depth topics such as proper testing, better ways of testing my code and how to approach dev related problems from a different angle. I’m sure every at MS South Africa and the presenters put a lot of hard work into DevDays and I’m not knocking them, but as a developer who tries to stay abreast of new technologies, I felt the day would be better served coding than watching people show me demo’s I’ve already done at home.