I’ve a read a lot of articles talking about what it takes to be a good development manager. There are also articles about what makes a good developer. I thought it would be a good idea to describe what a developer needs from their manager.

A developer abstraction layer – There is so much stuff that goes on in a company, and I really don’t need to know it all. For my own curiosity, give me general interesting tidbits, but more isn’t necessary.

Leave me alone – If you interrupt me for no reason while I’m getting a lot of work done, I’ll obviously get less done. It’s not worth interrupting me just to find out what I’m doing. If I’m walking around, that’s probably the best time to talk to me.

Buy any training materials that I request – Books are cheap compared to my salary. If I can learn something new that will save time, the investment will have been worth it. The same goes for magazines, software conferences, etc.

Be flexible – When it’s time to get some coding done, there are times that I’ll be more productive than others. My computer doesn’t care if I’m using it at 3AM or 10AM. You shouldn’t either.

Trust – If you don’t trust me, you’re setting me up for failure. Trust your employees first, and take appropriate action if they give you reason not to trust them. If I know you trust me, I can focus on getting my job done.

Keep me happy – A happy developer is a productive developer. Sometimes there are small things you can do that will keep me happy. Buy lunch every once and a while. Tell me to go home early on a Friday. As a bonus, I won’t be looking for another place to work if I’m happy.

Guide, but don’t over-manage – You have the big picture, so I need your guidance. That doesn’t mean that you have to know every detail about what I’m doing. You’re not a babysitter, you’re a teammate.

Be accessible – If I get need something, please be available. I may need you to pull in the right resources to solve a problem.

Have answers – You’re the hub of the wheel. If you don’t know what’s going on, you’re useless to me. You need to be organized and connected.

Be able to prioritize – You have a better idea of what is important for the overall product. That means I need you to prioritize features accordingly. That means I’ll always be working on something important.

Tell me what is expected of me – I need to know exactly what is expected of me, and I need to know how you’ll determine if I’m completing what is expected. I also need to know how you’re going to gauge my performance. When it’s time for my review, there should be no surprises.

If you’re interested in more information on this topic, I highly recommend you read "First, Break all the Rules – What the world’s greatest managers do differently". It’s not specific to development managers, but it certainly applies. In that book, they empirically determined the factors that are the most important traits that promote success and happiness:

1. Do I know what is expected of me at work?
2. Do I have the materials and equipment I need to do my work right?
3. At work, do I have the opportunity to do what I do best every day?
4. In the last seven days, have I received recognition or praise for good work?
5. Does my supervisor, or someone at work, seem to care about me as a person?
6. Is there someone at work who encourages my development?
7. At work, do my opinions seem to count?
8. Does the mission/purpose of my company make me feel like my work is important?
9. Are my co-workers committed to doing quality work?
10. Do I have a best friend at work?
11. In the last six months, have I talked with someone about my progress?
12. At work, have I had the opportunities to learn and grow?

That book is one of my favorites, and I highly recommend all managers read it.

Are there any other factors you feel are important? Leave a comment and let me know!

I think I’m finally starting to understand the Inversion of Control principle (aka Dependency Injection). I had a hard time understanding most examples out there, because they appeared to be solving problems that didn’t even seem like real problems to me. For years I’ve been writing classes, testing them, and hooking them together. In many cases, I was already practicing inversion of control. The benefit I wasn’t seeing was the fact that you can separate the modules in your code and the connections between them.

When you really commit yourself to breaking the problem down into manageable pieces, it does create more testable and reusable code. I already knew that, but when you starting using IoC, it really starts to drive that point across. It’s similar to the effect that unit testing has. When you start writing unit tests, you try to make your classes more unit testable. When you start using a dependency injection framework, you try to make your classes more open to injection.

So what is a dependency injection framework? It’s the glue that holds your pieces together. Without it, your classes would probably be dictating the classes that it depends on. With dependency injection, the application configuration tells the class what modules to use. A dependency injection framework separates the linking from the pieces.

In the diagram on the left, it’s a typical tightly coupled design. Every class is hooked up directly to another class. This doesn’t mean that each class isn’t testable, but it’s a very rigid design (which isn’t necessarily avoidable). In general, the easiest unit testing was in the classes on the edges, since they have a usable surface area.

The diagram on the right is closer to what I’ve been creating while using a dependency injection framework. In the first pass, I create pieces that contain my business logic. Then, I can use the dependency injection framework to declaratively define how those pieces are wired together.

At this point, I would have a hard time NOT using something like this. While this concept isn’t new, the frameworks have recently become very mature. Personally, I’m using Spring.NET and loving it. One of my pet projects for package tracking,(SimpleTracking.com) has been rewritten using a modular, test first, dependency injected design philosophy. I was able to reduce the amount of actual code by quite a bit, increase my testing coverage, and decrease the amount of duplicate code.

I’m sold!

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

No matter what your position is, one of the most important responsibilities is to know who your customer is, because they’re the one that you need to make happy. If you think it’s the where the money comes from, you’re probably wrong.

As a developer for a medium size company, I admit having made the mistake in thinking that sales were my primary measure of success. After all, I’m working on an e-commerce site for customers. I was wrong. My customer is actually the person making decisions about the features that go into the product. In a traditional software company, if you’re a developer, your customer is your immediate manager.

Here is a map of the value stream for a typical software company:

We can only be measured based on what we have control over. As a developer, you’re not talking to the customer, and you’re probably not picking the features that should be developed. What makes you think you can affect sales?

The development value stream is a hierarchy of levels designed to create focus. As a developer, you need to create features that exhibit quality, and you need to maintain a reasonable velocity. Each level in the hierarchy needs to be doing their job well, or the level above them will fail. Ultimately you do affect sales, but it is with an indirectly. Keep in mind that it doesn’t make you any less important.

Do yourself a favor today. Take a few moment to figure out who your immediate customer is. Then ask yourself what they expect. If you focus on that, you’ll be doing your part to make the company successful.

Today’s post is a case study of sorts, about my former employer, who had an interesting architecture. It’s roots were VB6 and SQL server (version 6 I believe). They decided to put as much logic in their stored procedures as possible. The arguments being:

• Easy to update (fix, improve) on-the-fly.
• Hard to work with data (multiple tables, arrays, etc) in VB6 and ASP, at least compared to .NET.

Given the circumstances, I don’t think that I would go back and change history if given the chance.

The problem is that the world has changed, and their architecture just doesn’t scale well. The biggest problem is in the area of reporting (which is now primarily .NET). Since all the data manipulation and logic is in the stored procedures, the database is forced to do all the work. In a small application with not a lot of data, this probably isn’t a big deal. The report runs for a few seconds and no one really experiences a slow down.

The problem arises when there is a lot of data. Easily millions of rows in dozens of tables. The current fix is to scale vertically, meaning that they throw more hardware (AKA money) at the problem.

The real solution to the problem is to scale horizontally. There are two main ways of doing this. The first is to add more database servers. The problem is that this isn’t really all that easy. The software to do this is getting better, but the fact remains that two different systems now have to stay synchronized. I’ve read articles about businesses that have scaled their business, and a common theme is that databases are one of the hardest parts of your architecture to scale.

The second aspect of scaling is to reallocate where your work is being done. You need to start thinking of the database as a…well….a database! The first and foremost purpose of a database is to store massive amounts of data, and allow you to quickly retrieve that data.

Databases are amazingly fast when you use them simply as a place to store data. If you design your database correctly, and set up indexes that are optimized for the ways you want to retrieve your data, there should be no reason to wait for your data. SQL Server can easily handles millions or even billions of rows, and query any of them almost instantaneously. Even with multiple queries being executed concurrently or in succession.

Consider the following diagrams:

The existing architecture is on the left, and the proposed structure is on the right. It’s not a big change, I’m simply suggesting that the business logic be moved from the stored procedures, into the code.

The first reaction that I usually receive from this suggestion is that the code is going to be ugly compared to the corresponding SQL. The reality is that the SQL is ridiculously complicated (at least in my experience). SQL is great for set based logic, but really starts to break down when trying to do object oriented or procedural operations.

The fact is that .NET is great at processing massive amounts of data. First of all, it’s incredibly fast. If you’re writing your code correctly, you’ll be amazed at how fast it can process data.

More importantly, if you’re using a programming language to manipulate your data instead of T-SQL, you can really start to break down the problem at hand. Databases are traditionally very bad at breaking a large problem into smaller problems. Sure, you can call other functions and stored procedures, but you can tell that it’s not the strongest feature of the database. A programming language like .NET lets you pass data around in any structure that you can conceive.

The other major advantage of processing the data in your code, is that you can now easily build testable code. Any code that you can easily test will have less bugs, and should be easier to maintain in the long run.

If your data is now being processed and organized in your code and not the database, you are probably ready to scale horizontally. It’s relatively easy to add more front end servers. Since they all hit a common database, there aren’t really any synchronization issues.

So does this really work? Of course. I’m not the first to think of it by any means. Take any of the largest websites on the Internet, and look at how they have designed a scalable architecture. Digg.com has always had database scalability issues with their MySql servers, so they try to minimize them as much as possible. Twitter uses ONE database server to handle thousands of requests per second. eBay.com doesn’t even do joins in their database. They would never be able to scale if they put that burden on a database that handles 26 billion SQL queries each day.

Microsoft has made matters worse by integrating the .NET CLR into SQL Server. You can now write .NET code that gets executed on your database server. This is a great tool, but it must be used with great care. This isn’t an excuse to write more code in your database.

In summary, databases are an expensive commodity, don’t abuse them! Be careful how much you do in the database, and ask yourself if you can move some processing into code, where it is more easily scaleable.

Just recently, Scott Hanselman came out with a podcast about website scaling. If you’re looking for more site scaling concepts, it’s worth a listen.