Software
Manuel Klimek has put an excellent list together for those looking to regain control of their team by demotivating each and every member. Checkout his Top 10 ways to demotivate your programming team to get started. Oh and while your at it you might as well see what you can do to build the Anti-Team (and don't forget these team members).
Crappy software is within your reach, go get it!
I’ve been happily running Windows XP on my MacBook Pro for at least 6 months, however, I recently got greedy and went searching for a solution that provided better integration and less rebooting. Since there’s been a lot of talk surrounding Parallels, I decided to give them a try. Since they provide a nice virtualization package that supports XP, plus they support having an image based off of BootCamp, and have Coherence as well (which makes it feel like you can run XP apps within OS X) it was a win win situation. Or so I thought.
Apparently something within Parallels ends up hosing BootCamp. I can no longer boot into BootCamp natively because it doesn’t recognize my mouse or keyboard (I tried both USB as well as the one’s on my MacBook Pro). There are a TON of forum posts on the subject and so far absolutely no response from Parallels. A couple individuals in the forums are ranting and raving about the fact that its beta and that's what you get but I think that’s bogus. At least have someone from Parallels come out and say something. Say…”Hey our latest build hoses your Native BootCamp image, here’s what we plan to do about it. Here’s when we expect to have a fix, and if you’re brave this is what you can try to manually fix it.” Don’t sit there silent while hundreds of customers and/or potential customers are going bonkers trying to figure out how to get their BootCamp setup working again outside of Parallels.
This is one of many bad experiences I’ve had since trying Parallels. The performance has been more or less unusable, the setup and configuration of my images never seems to stick, and now it’s completely screwed up my BootCamp setup which had been working flawlessly for 6+ months. And on top of it all they’re silent. Come on folks, say something, your silence is losing you customers.
tags: parallels, mac, bootcamp, virtualization
I've recently been considering a couple different options for backing up all the stuff I have on my PC's, external hard drives, and etc. to some remote location. While I have backups of some of my stuff, and do a decent job of replicating things across machines (thanks to Subversion) I really need to come up with a backup plan that involves computers that don't all sit inside my house. One obvious considering is Amazon's Simple Storage Service (S3). Another possibility is Mozy (hey it's free!).
Via Greg, I recently found S3Drive, which is a file system driver that provides access to S3 storage, very cool! What do you use to backup your life?
Nick Bradbury knows his stuff. He's created several extremely successfully software products, including one of my favorite pieces of software at the moment, FeedDemon. Nick has a series of posts that discuss the struggles the come with trying to make software simple.
As software developers I don't think we spend nearly enough time thinking about how we can make our software simple. We think a lot about adding features and functionality but are we doing so in the simplest way possible? Just because a feature was hard for us to code doesn't mean it should be hard to use. We need to strive for "simplicity", "elegance", and "beauty" in the software we produce.
Technorati tags:
feeddemon,
software
Via Kathy Sierra I came across Kevin Briody's post about the two simple words that he thinks passion starts with. In his post he talks about the raw, gut feeling, he wants his users to have when using his product. He wants them to feel passionate about his product and declare it "F**king cool!"
I agree. 
Dare has a nice post where he outlines his top five list of signs your software project is in trouble. When talking about his "Schedule Chicken" sign he says:
The main problem with schedule chicken is that you can be "date driven" or you can be "quality driven", you can't be both.
Well put.
Jeffrey Palermo has started a nice series of posts on how to produce a software product quickly.
Joel has
started a series on how to find
great developers. I was always amazed by the….how do I say….consistency of the “not so good” candidates that we saw at my last gig (lucky for me I don’t have to do nearly as much interviewing these days). Finding great developers is one of the hardest things to do in our industry. Joel does a great job of making people want to work for Fog Creek. I’ll be interested in hearing some more nuggets of wisdom from Joel on the topic.
A couple of week ago I posted about opinionated software and went as far as saying you might be better off ignoring your users and going with your gut. Today I think I’ll go a step further and say that I agree with Kathy that we should ignore our competition.
A lot of software that is built today is done so with a feature list that is a mile long. When building software we often feel that in order to be accepted we have to have every possible feature that our customers, competitors, and every one else in the world may have ever thought of. Rather then focusing on the core problem we let ourselves get distracted by the latest and greatest feature that was just announced in product X, Y, and Z. Not everyone can create great software. If it was as easy as implementing feature after feature over and over we’d have a lot more users with smiles on their faces. Instead we have overcomplicated software that has too many half done features and not enough simplicity. As I think about it I think a lot of it comes back to software not being opinionated enough. It’s a lack of opinion on things that leads to our software getting more and more features. Rather then having our own opinions we take the opinions of all of our users and we end up with a big mess of features that absolutely positively must be what the users want….afterall its their opinions that we based the whole thing on isn’t it?
In order to create truly great software you need to have opinions on how things should be done. You need to have a list of things that your product is, as well as a list of things your product is not. You can’t slap feature upon feature on top of your application and think it will be a success. Start “ignoring” your competition. Start “ignoring” your users. Maybe then you’ll develop your own opinion on what your software is about and create something great.
Ron Jeffries has a nice article about the impact of overtime on programmer productivity. It’s no surprise that his conclusion is that working longer hours doesn’t pay off. Over the short term it might look like more things are getting done but over the longer term you’ll likely end up with lower quality software with harder to fix bugs and lower morale among the team.
Joel’s latest article entitled, “The Development Abstraction Layer” offers a peak inside what happens within successful software companies. While I don’t agree with everything Joel says I think he (not surprisingly) hits a lot of things right on the head. Over the last few years I thought about going out on my own to startup a software company countless times. The fact that I wouldn’t have had any abstraction layer is what always stopped me. Well that and the fact that I didn’t have an idea I really believed in
Anyway, for those people working at software companies Joel’s latest article is a must read. As a “techie” he understands what it takes to get the most out of his programmers.
Gregor Hohpe delivered what sounds like an excellent “keynote” to a room full of Java programmers at the Server Side Java Symposium. Within his presentation he talked about how we need to write code with people in mind rather then the computer. We need to make beautiful code.
"Write code that people aren't compelled to mess up," he said. "Make code so the next person sees you put thought into an elegant solution."
"Write code for people not machines," was Hohpe's mantra throughout his keynote. He suggested that if programmers were only writing for machines, they wouldn't need Java, they could revert to working in Assembler.
"Where did all the beautiful code go?" he asked,…"Maybe the janitor comes in during the night and messes up our code?"
As a software developer, as well as a member of a software development team, version control is a critical aspect to the work I do. Over the years I’ve used several different version control providers with varying degrees of success.
The majority of my professional life I’ve worked with Visual SourceSafe (VSS). Although the experience hasn’t been stellar, I’ve actually had a surprisingly low number of issues with VSS…until recently. At home I’ve used VSS, Vault, and Subversion. Since at home it’s just me I don’t have many hard core requirements.
Ok, so back to the recent problems with VSS. Every since we’ve been using .NET 2.0 (which started with early betas) we’ve been having a lot of issues. I should note that some of these issues where specific to the VSS integration within VS.NET.
- Get latest takes a long time, and often hangs
- The pending checkins window takes forever and a day to come up and often hangs VS.NET
- While checking in files VSS bombs out which results in the repository becoming corrupted
- Repeated corruption problems
- Merge changes doesn’t exactly merge (sometimes)
Over the course of the last several months we’ve been talking a lot about moving to some alternative source control providers. Since almost everyone on the team had either had very good experiences with Subversion, or heard of people having very good experiences it came up as the best option in most of our conversations.
We’ve been running on Subversion for a couple weeks now and I’ve been very impressed. The top advantages that we’ve seen are:
- Must faster then VSS
- Checkouts over the VPN used to be impossible but are now very doable
- Our build time within CC.NET has gone down considerably (on the order of 3–4 minutes)
- TortoiseSVN is a nicer interface then VSS (integration with the shell is top notch)
- Atomic commits are a very good thing.
- Easy to setup – we were up and running in the matter of a half day
- Setting up the subversion repository took 3–4 hours since we had to figure out how to install it
- Importing our existing source took about 5–10 minutes
- Updating our continuous integration environment took about an hour. Most of that time was spent perusing the CC.NET help and trying to figure out why autogetsource “wan’t working” with subversion. It turns out that you have to do the initial checkout yourself on the build machine in order for this to work.
Funny side note: while spell checking this post BlogJet wanted to change VSS to ASS
In my previous post I mentioned that I believe that validation logic should live in the business layer
rather then in the UI. I went as far as to say you should have the rules for validation defined in one place, your business layer, and have your other layers use those rules to apply the validation as necessary. I’ve decided to write a series of posts on how I’ve implemented such a setup in my custom .net framework (I need a cool name for it like “Rails” or something 
). In this post I’m going to quickly show how I define validation rules in my business layer and talk through how I then use those rules within the UI. In future posts I’ll dig into more specifics of what the code actually looks like to apply the rules in the UI. Let’s take a look at a sample entity object:
public class Role : EntityObject {
public Role() : base() { }
public Role(int id) : base(id) { }
[Persist, Required, MaxLength(50)]
public string Name {
get { return _name; }
set {
SetDirty(true);
_name = value;
}
}
[Persist, MaxLength(250)]
public string Description {
get { return _description; }
set {
SetDirty(true);
_description = value;
}
}
[Persist, Required]
public int SiteID {
get { return _siteID; }
set {
SetDirty(true);
_siteID = value;
}
}
string _name = String.Empty;
string _description = String.Empty;
int _siteID = -1;
}
As you can see this is a simple Role entity that contains a Name, Descriptions, and SiteId. Within my framework I define many of the rules for how an object should be treated using a set of custom attributes. The [Persist] attribute tells the underlying framework that when .Save() is called on a role instance that particular property should be persisted to the backend data store.
From a validation perspective we can see two custom attributes that define some validation rules for the Role object. The [Required] attribute specifies what properties require a value to be set, and the [MaxLength] attribute defines the maximum length for the name and description property.
Every time a Save() is called on a role object the persistence layer will ensure that a Name, and SiteID is provided and that the lengths of the Name and Description properties are shorter then 50 and 250 characters.
The second piece of the equation is getting the rules defined via these custom attributes applied when people are entering roles into the EditRoles.aspx page. The easiest solution would be to drop a couple RequiredFieldValidator controls on the page as well as set a maximum length on the textboxes that users enter the name and description into. But what happens when my rules change? What happens when I decide that description should also be required, or when I adjust the name field to be 100 characters rather then 50.
If the validation rules where defined in both the business layer and UI layer I’d have more then one place to update my validation rules. Those of you familiar with the DRY principle know that this is far from ideal.
Instead what I’ve done in my framework is applied the validation rules defined on my business object to my UI. One of the wonderful things about ASP.NET is that you can add and remove controls from pages at runtime. What this allows me to do is dynamically inject required field validators into my ASP.NET page at runtime by inspecting the rules defined on my Role entity. This keeps the rules defined in one place and helps me to sleep better at night knowing that nobody is going to get a Role into my system without a name. What a relief!
Rhocky has an interesting post which poses the question...
Should validation logic be in the UI or in business objects?To get right to the point,
validation logic should be in your business object layer. End of story.
Ok, it's not really the end of story I have more to say on the subject. As Rhocky points out in his post most (if not all) asp.net applications have all validation logic in the UI only. For some trivial applications that might be enough but for most applications that doesn't cut it.
Rather then focusing your attention on getting all the validation logic setup in your GUI you should instead be focusing on how you can define the validation rules in one place and have it applied in several different scenarios. By putting validation rules in one place you can then use those rules to perform validation in your UI, as well as within your business layer. This helps you ensure that you don't end up with any invalid data in your system.
[1] The rules can be applied before your data layer saves your objects to their persistance store and the rules can be retrieved by the UI and used to dynamically build the UI validation necessary.
So I'm guessing at this point I have a lot of people thinking that theoretically I'm on the mark but actually going and implementing something like this is another story. Since the specifics of how something like this could be done is a little beyond the scope of this post I'm going to leave you with this. It can be done, and once the groundwork is laid you will be very pleased that you spent some extra time getting it setup. It's extremely nice to be able to define your business rules in one spot and have them applied when your objects are saved as well as when UI screens are rendered to the user. I've implemented such a framework in the web world while building
ActiveType as well as in the Windows world. To be fair I've just started developing something for WinForms, but I'm confident it's going to work
To conclude...rather the placing validation rules directly in your UI or duplicating them in both your UI and business layer think about how you might be able to define them in one place and have them applied in multiple scenarios. I'll dive into some of the details of how I've done this in the web and WinForms world in future posts. Maybe I'll even include some code *gasp*.
[1] This of course assumes your not letting people access the backend database directly in which case the rules that aren't enforced in your database won't be applied.