Resharper has been discussed before, and for those who love it, hate it, or just don't know about it... The early access program has begun.
For those of you who don’t know, ReSharper is a plug in for Visual Studio .Net that adds in a bunch of refactorings, navigation helpers, and other stuff that just makes you more productive. There are separate downloads for VS2003 and VS2005.
You can find the download here.
Update: After trying it out myself, I found Rick's follow-up post on Resharper 2.0. I have the same problems that it keeps crashing my Visual Studio. It also consumes even more memory then the previous version. As before (I tried the beta of 1.0) they need a lot of work before people can really use this. I will keep my eye on it though, after my first experiences with the 1.0 beta, I threw it away and totally forgot about it.
As you have probably noticed, Blogging About .NET has been 'upgraded' to Community Server. It was pretty painful, because of various reasons. For one, I had to do a complete testrun at a local machine. It took several hours converting the database and some time setting up Community Server. I immediatly noticed that the application name was used as display name. My applicationname is Dennis, is it says in the url. That and some other problems, made me do some fix runs on the (copy of the) original database, before doing another testrun.
After getting it setup, I wanted to have another frontpage, as the original is to basic. So I used the templates from CodeBetter and implemented them here. They have some additional changes that I want to implement in here as well.
Then I got a new host and finally I was ready to try and get Community Server up and running there. But when uploading the converted database onto the new domain, all objects had the wrong owner. So I had to fix some things here and there as well. Finally I thought I had everything as it should be, but it kept refusing to show the errors, even though I had customErrors="Off" in my web.config. After a struggle I decided to wipe everything clean and start over with a clean Community Server install, without my database. Only then I noticed the error turned up again, right after I had updated my web.config. I dragged it into Internet Explorer and it showed me same bad characters. As I can see now, Wordpad screwed up my web.config. After loading it in Notepad and editting it, everything worked fine. I then uploaded the database and the new BloggingAbout.NET worked flawelessly!
Then it was time to transfer the domainname to the new DNS servers, which took about 2 days to complete. I always thought it would just transfer me to either the old or new file, but now I know it keeps transferring you back and forth, depending on what route you get send to. This goes for a lot of files, so sometimes I was looking at the new site, but with the old cascading stylesheet (.css). Everything should now be okay though.
A few things I have to complain about Community Server.
I'll have a look if I can add and/or change some functionality to the way me and our users want it. But it'll probably be a lot of work when a new version of CS is released. I'll have to implement all changes again with a good possibility that they've broken some interfaces in the internals of CS, like with 1.1 happened.
David Anderson nearly choked on his sandwich recently, because his wife said : “You know it really pays to be thorough. All that rework is really time consuming and it uses a lot of paint!” For him, there was hope after all that his wife might understand what he does for a living.
After the, a great story is told on how he painted his fence the Agile way, including calculating velocity, sprints, getting the right tools, etc.
A few years ago two colleagues and me were asked to help out in some project that wasn't doing very well. They told us they needed some experts on software development. Before you can say anything, I also am still shocked they sent me. But seriously, after spending a few months there, my opinion on what they actually needed, were an airtight contract and airtight functional specification. To my surprise, they actually said that they left/wanted holes in the specs so they could argue over details with the customer. Before some might think this was to come to a mutual agreement, I have to make clear that most of the time these were last-minute discussions about who was right about a lot of functionality that was vaguely described. Resulting into a customer most certainly not trusting the company that supplied them with the software they wanted. This had been going for quite some time now, until we were brought in to rescue the project. Of course if they had brought in an army of the best developers, they would not even succeed. What I had come to learn, was that they needed an airtight functional specification, instead of the one with so many holes that all raised questions.
You can imagine that I was very surprised to learn that Agile Software Development also drives on open documentation. (Of course this is comparing apples to oranges, but read more on Agile here and here.) But all the openness cannot be without trust! And the relationship between the customer and that employer certainly wasn't based on trust. Trust is the melted cheese that binds everything and everyone in the project together. And as David Anderson goes says, trust is the grease that takes the friction out of the software engineering economy. An excellent example he uses are the merchants from my own country, the Netherlands, where 200 to 300 years ago the trust among each other brought us great wealth and established the Dutch Guilder as the World's reserve currency. (And then the European Union came along and brought us the Euro and almost 100% inflation, but that's a different story.)
Also most excellent is what Mary Poppendieck and Tom Poppendieck had to say about trust in their book Lean Software Development.
"Conventional wisdom holds that specifying and controlling scope in a contract is necessary to protect an organization from self-serving behavior on the part of the other party. However, the effect of this protection is a sub-optimized value stream... The bottom line? Organizations that use outsourcing as a way to save money will save more money overall if they collaborate with vendors by using some form of optional scope contract."
I'd think that is very hard to proof, as you can probably only get that proof from real life experience and measuring. Read the book or the chapter about contracts here in pdf, read more here as well. In the example chapter from Lean Software Developement you can read about Toyota and how they've gained trust from their suppliers, because they thought (and proved) it is important to have a strong network of suppliers then short-term benefits that come from taking advantage of a supplier. The article compares Toyota with GM and shows where and why Toyota does much better, because of the trust. They take the parallel to IT Software, fixed-price projects and time-material. An interesting read, also for developers.
I think in most projects I've been in, there is enough trust among developers. But when it comes to trust between developers and the project manager, that's on a whole different scale. Developers don't always trust their project manager to do what's best for them and/or the project. I think this also has to do with the fact that project managers don't always tell the whole story. And perhaps that's also because of a lack of trust. And as Mary and Tom Poppendieck wrote in their book, many people think that the reason for contracts is the substitute for this trust. Conventional wisdom says that all eventualities should be spelled out in a contract, so the parties cannot possibly take advantage of each other. From there it's a long way to trust.
Of course there's always some form of trust. Most of the time, I've noticed that a lot of our customers trust us to send competent people to help them solve problems. But I don't meet many customers that trust their supplier enough to trust them into getting Agile, where a lot of specifications -be it contract or functional- are left open. Perhaps you have different experiences?
If you're interested in SOA (Service Orientated Architectures), SOD (Service Orientated Design), SO/A (Architectures based on Service Orientation) or whatever you want to call it, a very interesting set of articles is on the way. The first installment is already here and it's called Dealing with the Melted Cheese Effect.
Christian Weyer, Maarten Mullender and Beat Schwegler have joined together to create this serie of articles, about pasta and cheese and how sticky the cheese should be.
Architecture is design, and design is about making trade-offs. It's a trade-off between the cost of change, the ease of building, the ease of maintenance, the required performance, and probably many other important aspects. This is not about making one bowl of pasta, it's about providing a good recipe to make many bowls of pasta, a recipe with a sauce that tastes good, has just the right stickiness to it, and changes depending on who is coming to dinner.
In other words, it's about designing loosly coupled webservices with the help of contract first design. Of course with a reference to Christian's WSCF tool.
Hopefully the follow up articles will be posted soon, as I have a feeling some practical/hands-on experience will be in the articles, instead of some high-level bloating I am used to read.