Google+

Focus is the key to success

I'm certainly not the first to say it, and I'm sure I won't be the last. The software/Internet world requires focus as much as any other industry, if not more.

Focus Magnifying Glass

The number of platforms, technologies, and frameworks has been growing at an amazing pace. Nearly every month Amazon announces a new web service that adds to their cloud computing arsenal. Google has also recently announced Google App Engine, an entire framework to build scalable web applications.

Every time one of these new technologies comes out, I'm tempted to write something to utilize it. I would get the benefit of learning something new and exciting (which is often worth some of my time), but I have to remember to remain focused. Focus doesn't mean ignoring what is out there, you obviously have to be open to new ideas and knowledge. Focus means spending the majority of your time on a single goal, to make something amazing.

If you want to write a successful piece of software simply fill a need. There are plenty of gaps in the software that is available, and what is currently needed. To reiterate:

  1. Identify a need
  2. Fill that need well
  3. Fame and fortune

What prompted this post? Right now, I own 18 domains. There are about 5 of them that I'm currently juggling, and it's not not working. I used to manage about 10 of them, and I had to make cuts. It's time to start cutting and consolidating again. I can only realistically maintain 2-3 sites. I'm sure a lot of my readers are in the same situation.

How do you figure out where to focus?

  • If you don't have Google Analytics set up on your sites, I highly recommend you set it up. It's free and easy. I now have it set up on all of my sites, and it's helped me see which sites are not very popular.
  • Ask yourself what your talents are, and think about where they are best applied. I've thought about starting a lawn mowing business because it looked like easy money. The problem is that it doesn't use any of my talents. Your talents are what will allow you to create something truly amazing.
  • Choose projects which passionate users. Passionate users are usually going to be your best customers, and they're very hard to find.

Once you see which projects you should be working on, do yourself and everyone else a favor. Focus your time and energy on those! Nearly every successful person I've spoken to says that to be successful, you need hard work and persistence. None of them have said to spread yourself thin.

Like this post? Please share it!

See a mistake? Edit this post!

Do you really need a data access layer with LINQ?

Lately I've been giving a lot of thought to using LINQ to access my database instead of using NHibernate. I've been a little confused as to how LINQ would work in a data access layer, but I'm starting to think it makes sense as a replacement to the data access layer.

This article was inspired by the Google App Engine. Using the Django framework for database access is stupidly simple. They're able to focus on getting something done, which is good enough in a lot of cases. Not every project has to be an N-Tier enterprise application.

Primarily, I write eCommerce websites. Consider the following diagram, which gives you a rough idea of how I've traditionally structured my applications:

Traditional Architecture

Notice that a lot of code is being tested. The sweet side of me likes unit tests, but the wheat part of me is telling me to simplify code when possible to minimize the need for unit tests. I've traditionally wanted a lot of unit tests at the data access layer because it tends to be a source of a lot of issues due to it's complexity. It's complexity is a result of impedance mismatch.

Code that is a good candidate for unit testing:

  • Logic/utility/static functions
  • Code that will be used in a lot of places, and has a well defined contract
  • Code that needs the highest levels of reliability

Now consider what happens when we use LINQ and the ADO.NET Entity Framework.aspx). The impendence mismatch has been minimized because the entity framework has automatically written our model code to match the database. It has also been my experience that the queries that are not trivial are usually not re-used. In other words, query complexity is inversely proportional to the frequency of re-use.

The end result is that our code has been greatly simplified. Now our unit tests can focus on the business logic. We'll actually have more time for unit testing, which should lead to more stable code where it is needed most.

Sure, our UI will contain what are basically database queries. The fact is that many pages simply need a specific set of data that will populate a drop down list for example. I know that it might give people a bad feeling (as it does to myself), but I think it's something we need to get over. If you want to test the page, in most cases you can just run it, and see that it's working. In conjunction with a good web testing tool, it would be easy to have high levels of reliability.

Linq Architecture

Obviously there are a lot of places where this is a bad idea. I'm certainly not condoning a complete lack of a data access layer for every application. I'm applying the 80/20 rule. Places it might not make sense, or where it's gray:

  • A logic class that needs to make frequent, repeated database calls.
  • An application that requires a certain level of testability.
  • An application that contains some extremely common queries that may or may not be trivial.

Like this post? Please share it!

See a mistake? Edit this post!

Filtering the noise from above into a working plan

In this post I'll talk about a few ways that you can deal with the common influx of requests that come in for a software team.

I used to work for a large company affectionately known at the Borg. I was fortunate to work in a division of the company whose product was a software package. This essentially meant that I worked for a software company.

Borg Cube

My current employer is a mid-sized business, and we're not in the software business at all. My primary job function is writing custom software for certain customers, as well as creating the "glue"; that holds together the software packages that we have purchased.

Luckily, we're a growing company, so we're starting to have a real software development team. With that comes with the pains of getting organized, and making sure we're working on the right projects.

What do you do when the amount of work being requested from management greatly exceeds the amount of work your team can actually get done?

  1. Push back - This doesn't have to be negative. The person requesting a new software project might not understand that you're team is busy. It's common to think of an IT department as overhead. They are usually not factored into the costs of new projects. A good manager will be able to explain the situation, and either delay the request, or drop it completely.
  2. Set up monthly meetings with the key management members - This gives people a forum where they must discuss the work they're asking to be done. At this point, a good percentage of the work could disappear, because no one is willing to try to justify the importance of their project. Some of the projects that would normally be high priority are now not as important when compared relatively to all the work that needs to get done. This also gives management members time to negotiate directly with each other, and you won't be caught in the middle of it.
  3. Create a visible schedule of tasks that need to be done - When a member of management wants their work done, they can look at the schedule and see that they are not alone. If they want something done, they may have to negotiate with someone that is already on the schedule. If they can do that, they probably deserve to be on there.
  4. Associate a cost with all work to complete - For any tasks that take longer than, say, 2 hours, require that the time be charged to a particular task. That time can then be equated with money. Since your time now has a set cost associated with it, people that need your time will have to pay for it. Actually money doesn't have to be exchanged, but just associating costs will put the burden on the person requesting it. If they have to justify $100 worth of time to save $50, they might think twice.

Do you have any other tips for dealing with this situation?

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