Customers trust you, even if you don't deserve it

Jeff Atwood over at Coding Horror had an interesting post about sites that ask for your email password to lookup contacts in their system. He suggests that they stop doing that immediately, and long-term, find a more secure solution.


I can understand where he's coming from. He doesn't want to hand over the keys to all of his information.

I see things a little differently, because I've been on the other side of the fence. Imagine that you're writing a site and your #1 goal is to make it easy to use. Jeff himself is a huge advocate of usability. The problem is that developers don't have an unlimited amount of time. The quickest way to make something easy to use at this point is to simply ask for the information, grab the addresses, and be done with it.

I agree that if the major email providers provide a more secure way to access the data, it's certainly worth investigating.

The second point I'd like to make is that Yelp probably doesn't care that Jeff won't give his personal information. It's an optional step to save him time, and even if he doesn't use the service, he probably represents only 1% of the users that use the service.

I'm very paranoid when it comes to passwords. I have automatically generated random passwords for every site that I use. I still have been trusting enough to give sites like Facebook my Gmail credentials to go check my address book. I should be changing my email password on a regular basis anyway.

The fact is that 99% of users will happily give over any information **that you ask for.**

When I do computer work on the side (which I'm trying to avoid these days), I'll ask for a certain password and strangers will happily give me all of their personal information. Bank account passwords, email passwords, work passwords, etc. I try to tell them they shouldn't do that, but you're not going to change everyone's attitude overnight.

Remember, more than 70% of people would reveal their password in exchange for a bar of chocolate!

I'm sure those services in question would like to have a better solution for accessing the data, but it's probably at the end of a long list of potential features. The only way that's going to change is if they start losing a significant number of customers over it.

Like this post? Please share it!

See a mistake? Edit this post!

Improve your software by creating an API

I'm going to talk about the benefits of having an API for your product, and why you should consider building one for your next project.

I used to work for company that developed manufacturing software. Now I'm on the other side of the fence. Since I work in the IT department, I'm asked to help in evaluating the software that our company will use. One of our main tasks is to write the glue that puts all of the other pieces together. We know we'll have to fill in the gaps with custom software, since no boxed software is perfect for our custom process. Those gaps could be missing functionality, or it could be code that hooks up two systems so that they work together.

So what is the single best thing you can do to help people like me out?

Have an API for your software!


If your software has an API that lets us read and write the valuable data in your system, it's going to save us a lot of time. If we have to start modifying data in your database, we have to worry about tables changing. Worse yet, you might be using a type of database that we're not familiar with. That's only going to make us less likely to upgrade.

The great part is that this makes your software easy to sell. If someone asks for a feature that you don't have, you can tell them that your great API supports it, and their IT team could easily build that custom functionality. Better yet, they may contract you to build it for them. You can avoid saying "no", which can sometimes be the kiss of death for a potential sale.

What else can you do to have a great API?

  • Try to avoid being restrictive on how the data is queried. The Flickr API is a great example of allowing full access to just about everything, and allowing it to be queried in an amazing number of ways.
  • Try to maintain backwards compatibility when possible
  • When necessary changes are made, have a list so that our software can be updated
  • Have great documentation, which some clear examples

If you want to make sure that your API can truly get at all the data a customer would want, then why don't use use it yourself? If your own product is built on your API, it will be another selling point, as well as a guarantee that it fulfills the need. It also ensures that the layers in your software are not blurred. You will have a clear, well defined way that all data is moved in and out of the system.

Like this post? Please share it!

See a mistake? Edit this post!

Managing the number of output assemblies

A while back I had a discussion with a coworker about whether to have a few number of DLL's (.NET assemblies), or a lot, each with just a little bit of functionality. He ended up with some assemblies that had as few as one class.

For example, let's say you're writing an order management system (this is a completely fake example). Do you put everything into one assembly (like the left column), or do you separate out everything as fine grained as possible (like the right column). Or do you use an option somewhere in the middle?


In most languages, such as .NET, your namespaces can easily be organized independently of your assemblies. This means that you can have a DLL for each class if you want, or cram everything together into one giant assembly.

So how do you choose? The good news is, you might not have to make that decision right now. My recommendation is to start by favoring a small number of assemblies (or even 1), and don't play the "what if?" game. As assemblies are needed independently, it's fairly easy to split them up.

If you have multiple projects, you'll probably want to define clear layers of code. For example, you might have separate assemblies for the following:

  • Code that is common to all projects in your company
  • Code that is common to the set of projects that belong to a similar functional group. For example, you might be working on reports that share common reporting functionality.
  • Code that is specifically designated as a framework for a certain application.

Fewer Assemblies

When you use fewer assemblies, you can drastically reduce compile time. There is quite a bit of overhead to compile a single project within visual studio. If you have to continually build your solution, a high number of solutions will slow you down. I've actually seen this have a fairly high impact.

Using fewer assemblies means that you'll spend less time setting up and maintaining project files. This could mean big time savings if you have to add references or compiler constants to all of your projects.

Assemblies also have a certain amount of overhead. Multiple assemblies will decrease your ratio of code to overhead. That translates into more data for the application to read and manage. For situations where the assemblies are local, this is a moot point. For remote applications, the combination of the latency and the overhead can double the amount of data that must be retrieved.

In your build process, more assemblies can make your installer harder to maintain. You'll end up spending more time synchronizing your required DLL list with the build script.

Many assemblies

Of course, there are times when more assemblies does make sense. If you're writing an application that does not have a fast connection to the assemblies, you probably don't want to make the user wait for the large ones to load. In that case, you should try to optimize the assemblies based on what a typical user would use. For example, the main form of an application might be the first assembly, and reporting functionality might be another. The user shouldn't have to wait for reporting functionality if they are unlikely to use it. If they do use it, the assembly can be downloaded and used on demand.

Depending on your release and patch policy, using multiple assemblies might make it easier to manage patches. Once you replace a DLL, it's difficult to manage it if you have to replace it again to give the user a different fix. For a single assembly, the number of patched DLL's could start to multiply. For example, if you have 3 fixes, they could be applied in 8 different ways (2^3);

In summary, make sure you at least consider the following factors:

  • Speed that the assemblies can be obtained by the application
  • Latency of the connection to the assembly location
  • Code maintenance overhead
  • The typical of functionality the user would use (vs rarely used screens or functionality)
  • Patch/release policy
  • Solution & project management
  • Build management
  • Installer management

Like this post? Please share it!

See a mistake? Edit this post!

Jason Young I'm Jason Young, software engineer. This blog contains my opinions, of which my employer - Microsoft - may not share.

@ytechieGitHubLinkedInStack OverflowPersonal VLOG