Aranya Web Site Blog Posts

Android App Development

Sun, 01 Jan 2012 05:00:00 GMT

Android App Development Part 1

In this series I will cover some of the things i have been working on for a few different Android Apps.

The first app that i wrote took all of 30 minutes to write, a simple Hello World example. This app whale useless for any particle use, was the stepping stone to bigger and better things.

One of the apps that i am currently working on is and administration interface app for the KayaCMS Content Management System. This app uses several different layout schemes, dialogs, and even calls other apps to do some work.

Here's the basic layout of the main screen.

Should a Business Owner Care Which Programming Language is Used?

Fri, 30 Sep 2011 15:45:00 GMT

Should a Business Owner Care Which Programming Language is Used?

There is a lot of discussion out there about the programming languages. Which one is better? What should you use for your web application? Most of what you find is rather technical and the debate sometimes sounds more like religious fanaticism than logical comparisons.

As a business owner, do you really care? Java? .NET? PHP? Ruby? The list goes on. But do you have to know or even care? Just how much time do you spend choosing a technology to use for your web application to make sure you choose wisely, without wasting time you need to spend on other things?

The simple answer is that the selection of the right technology is important but not necessarily difficult. The level of importance depends a lot on what you do and what assets and skill sets you start with. But for the most part there are only a few options you need to consider and the factors you use to make that decision are straight forward.

Now keep in mind, we are about to simplify the issue for you. We want to make it easy for a non-technical business owner or manager to make a selection without having to become a technical expert. In light of this goal, we will start by narrowing our focus on the most widely used languages having the largest amount of existing capabilities and having a sufficiently large number of people out there you can hire to get the job done.

If you are a developer and feel we have unjustly left out your favorite web application development language, remember that we are not interested in including everything. We want to focus on what is important to business owners: quick, high quality and inexpensive web development.

To help focus on languages that are most useful for the business, we will restrict ourselves to these more popular choices. They are:

Web server languages

Java
.NET (C# and VB.NET)
PHP
Python
Ruby on Rails

Now that we have a short list, how do we choose? The best approach is to ask yourself a few questions.

What technologies do I currently employ?

Does your business already have a large number of computers, servers and software? If so, you want to take inventory of what you use.

For those companies that use exclusively Microsoft software on their servers, you probably want to heavily consider .NET with C# and VB.NET. The consistency of vendor software across most or all of your systems will help with support, specialization and expertise of your staff and make integration across software applications much easier.

Of course, all the languages listed above will run web applications on Microsoft Windows. Your web application can be build on something other than .NET. If you are concerned about vendor lock-in (here often called "being married to Microsoft"), you may want to be careful. However, if you feel that vendor loyalty can strengthen your relationship and support, it can pay off.

If your company uses Linux, Mac or Unix servers, .NET is out. You can run .NET applications on Linux but it is not generally recommended and can lead to complications with the development and unexpected problems and costs. The rest of the language choices are all good choices for these server platforms.

What skill sets do I currently have or will have available?

This is probably THE most important factor in making your decision. Who do you have - employees, contractors and preferred / trusted vendors - and what skill sets do they bring to the table?

You should take inventory of what these individuals know and ask them what their opinions are. Even if they choose a language that isn't necessarily recommended here, they may have some deeper knowledge or expertise that makes their chosen language perfect for you.

Based on the skill sets of those you bring in to help with your web application development, if you do decide to go against recommendations listed here, you should at least challenge your team with why they want to use their chosen technology. Make sure these reasons are synergistic with your business needs and are not simply because it is what they like - take the emotion out of the equation. Above all, make sure they have addressed current and future needs of functionality, cost, time to market and future growth.

When it is at its highest use, how many people will be actively on the application all at the same time?

You need to start off by being realistic with answering this question. All too often entrepreneurial business owners become optimistic. They overestimate how many paying customers they are going to get.

Get an idea of how many users you will have when you first get started. Unless you have an existing customer base that will eagerly jump on board, it is highly likely you will start with a very small number of users.

Next, project the growth of users. The timeline for this growth is good to know but not super critical. You just need a general idea of how fast you will need to grow to keep the business going.

If you are going to need to support only a small customer base or your customers will use the web application infrequently, you won't need to be too concerned with supporting a high number of concurrent users (users all on the web application at the same time).

If, on the other hand, you expect to see a large number of concurrent users, you will need to be prepared to scale your web application to service that large number of users.

Small-scale applications (web applications that don't need to support a large number of concurrent users) can get by with any of the above languages.

Large-scale applications, on the other hand, will need a more enterprise level, scaleable software supporting them. This is most easily achieved with Java or .NET. Typically the largest companies use Java for their most heavily used systems. .NET can scale but can also be a little challenging and expensive if your user base is enormous.

How complex is my web application?

Does your web application require a large amount of complex logic, back-end processing or integration with other systems?

If the answer is 'yes', you should consider more of an enterprise level web development language like Java or .NET.

If the answer is 'no', and your web application is fairly straight forward, you may be better suited with selecting a simpler language like PHP, Python or Ruby on Rails. PHP especially is heavily used for web application development and there are a large number of pre-built systems out there that require very little custom programming to get you what you need.

How much money do I have to spend?

If you are running on a very tight budget, your best choice is likely to be one of the easier languages like PHP or Python or possibly even Ruby on Rails. (Of course, it is becoming more and more common to find web application development firms that can provide Java and .NET development without a large expense.)

If, on the other hand, you are willing to pay a little extra for the ability to scale your application or to set a good foundation for business growth, Java and .NET are a better choice and worth the extra investment.

How confident am I that what we build will be exactly what I need the first time through?

Unless you have worked for companies that have similar web applications or you are working on a new web application that is similar to one you already have, it is highly likely you will have to make changes after the initial web application development effort is completed. The initial offering will be your first test of the market and customers always surprise you.

If you really have no clue what to expect and your effort is more of a proof of concept, you should consider looking at Ruby on Rails. This web application development platform was specifically designed for rapid build and prototyping. There are ways to get rapid prototypes with PHP as well. However, Java and .NET are a little more difficult to use for this type of effort.

If you expect changes but know these changes will not require a full rewrite of the web application, just about any of the other options will suffice. The key will be to choose a web application developer who is used to working with businesses and making these changes. These more experienced developers can then make sure the initial web application build is done in a way that facilitates easy modification.

Web user interface languages

There are two sides to the web application development coin. One is what will run on the server. That was listed above. The other is what will run on the user's computer (inside their browser).

The options here are much smaller and the decision much easier to make. They are:

Java Applets
JavaScript
Flash / Flex with ActionScript
Silverlight

Do I need to support rich multi-media?

Video games and web applications that are heavy in animations, screen drawings and rich user interaction will likely need a technology designed for this more complex user interface. This is where you need to consider Java Applications, Flash / Flex or Silverlight.

Most web applications are simple enough not to need special technologies to manage the web site. If the most you will need are simple animations and a few cool sliding windows or menu drop downs, JavaScript will suffice. JavaScript is the only one of the above technologies that is guaranteed to be available to the user. The others require installed plug ins and are more complex and costly to build and maintain.

What technology am I using on the back end?

If the answer is .NET and you need rich multi-media (games, fancy video and animation along with user interaction) then you might consider Silverlight. It is a Microsoft technology. It will run on a Mac as well as Windows. However, if you are not using .NET, you may want to discard Silverlight as an option.

If you are using Java on the back end and need rich multi-media, your best bet is to use Java or Flash / Flex. This technology is provided by Adobe which also offers products to help integrate Flash and Flex into Java based servers.

For the remaining languages, if you need rich multi-media then usually Flash / Flex is the best choice. This is because it is more heavily used, has been around much longer, has greater support and there are more developers available that have mastered the technology and its tools.

What devices will my customers use to access the application?

If you are wanting to deliver web applications to the iPhone, iPad, Droid phone or Droid pad then you want to stick to using JavaScript only. If you need rich multi-media, there is the promise that JavaScript will be able to handle that reliably on all browsers in the near future. For now if you must deliver rich multi-media to a phone or pad device you may have to resort to creating specialized applications for each device.

What kind of "cool factor" do I need in order to impress people to buy from my business?

You can get a lot of "cool factor" now from JavaScript. I am always surprised to see web sites that continue to use Flash for fancy looking animations. They look fancy but are often really simple with JavaScript.

However, you still may need to fall back on a technology specifically designed for the rich multi-media. In that case Flash / Flex is often the choice.

Digging Deeper

In the event you want to know more before making a decision, there are a number of comparison web sites that help you understand the pluses and minuses of each technology. Check into what similar businesses in size and market use. And do a little Google searching based on what your team has recommended.

If you love statistics and want to see some details on what these languages are and how they are used, check out this article on the Ten Programming Languages for 2011

If you are interested in the popularity of programming languages, check out this site.

The Perfect Balance - Using Your Time and Money Wisely

Sat, 10 Sep 2011 17:00:00 GMT

The Perfect Balance - Using Your Time and Money Wisely

Most software projects fail.

I am not sure what the exact statistics are now, but not long ago it was about 80% of software projects that failed. From what I still see, this hasn't changed much, if any. Just like with starting a business, when designing and building software, there is a very high failure rate.

So why do software projects fail so readily?

The vast majority of the time the project is destined to fail before it even starts. Poor planning and communication are the biggest problem.

Let me make this very clear: It is ALMOST NEVER the idea that is the problem. It is ALMOST NEVER the construction of the software that is the problem. It is more likely to be people pulling the trigger too quickly with too little preparation. Another common problem is little or no emphasis on good sales and marketing of the product but this is really part of that initial planning.

The Perfect Balance - Using Your Time and Money Wisely

So should you spend tons of time and money planning and documenting your project in great detail? No. There are always the extremes of too much and too little. Too little planning is what often leads to failure. Too much will drain your resources before you have something to start using and benefiting from. There is a happy medium.

To help ensure your software project is a success, the first step is to extract out the minimum number of features you can to get the application out there ready to use. This helps minimize the cost and time but it also reduces the complexity. Less complexity means it is easier to understand and build.

We like to encourage our clients to deliver their applications in small incremental chunks. This allows them to get something out and in use quickly and with a smaller monetary investment. That means you can start saving or making money (if that is the purpose of the tool) quicker and create a cash flow to pay for further development. In short, there is a much lower initial investment before the tool starts to pay for itself.

It also gets the application in front of users so you can start learning what they want. It is always surprising what feedback we get from users on what they like and don't like. Getting something out quickly helps you adjust the product and gain greater customer satisfaction and attract even more customers. It accelerates business growth.

So what is the cost of making a mistake up front? This really depends upon the severity of the mistake. Again, the smaller the initial application is, the easier it is to change and fix problems. It also means the fewer mistakes you would make up front before getting valuable feedback from your customers.

With a decent level of planning you can reduce the cost of mistakes dramatically. Remember, no matter how much planning you do, you WILL make mistakes. Mistakes are how we learn. Don't be afraid of them. However, you want to minimize the severity and also reduce the number of mistakes you could likely make.

This is where the perfect balance between too little and too much planning resides. You want to do just enough planning to eliminate the majority of possible mistakes and address the biggest potential problems. Then you move forward in small steps and learn. It is like a baby first learning to pick themselves off the floor, then to crawl, then to walk and only then to run. They fall down along the way but because they take these small steps they easily get right back up and do it again, even better the next time, until it is simple and easy.

So how do you know when you have spent enough time and not too much time planning? How do you know it is time to pull the trigger and start your build?

There are a few steps we take our clients through to makes sure we minimize the time and money investment up front and get started on building the software at the perfect time.

Picture What You Want - Analysis and Design

We begin all projects by sitting down with a client to draw out what their application will look like and how it will function.

This isn't the pretty graphical design look. While that is important, you first need to get an idea of what you want on the screens and how the screens must flow together. The graphics can be applied once this has been solidified.

What we are talking about here is sketching out on a white board or on paper what screens need to be built, what is on each of those screens, how the screens flow together and what happens as the user navigates through the system.

In most cases we have found that this process can be done in just three 2 - 3 hour sessions over the course of three weeks. This allows time for everyone to digest what was covered in each session and for us to document the design. This documentation follows the industry standards and will help subsequent design sessions move more quickly and also be critical in ensuring the build of the software is done as expected and done quickly.

Walk it Through - Usability Testing

In the final design session, we like to take a paper version of the application and place it in front of you, the client. This allows you to actually "use" your program before any time or money is spent on the build. It frequently results in finding disconnects between what you are thinking and what we are thinking and eliminates the miscommunication that can occur from time to time. It also allows everyone to see where the application is cumbersome or confusing to use.

At this stage sometimes features are added and sometimes they are removed or simplified.

This final session is most beneficial in making sure the application is easy and fun to use. It gives us the ability to feel what it is like to use the tool just as your end users or customers will. And if it makes you feel good, then it is likely to make them feel good. And if they feel good, it will compel them to use it.

The Architectural Plans - Solid and Simple Documentation

It is very rare to find systems that have good, solid architectural documentation. In fact, it is very rare to find systems that have any architectural documentation.

The documentation I am talking about here is that necessary for programmers to understand and work with the code. This is highly useful when bringing on new developers.

We inherit a number of applications that were written by other developers. We have NEVER (please let someone make this statement no longer true!) received useful documentation on how the application works when we got started. The best we have ever hoped for is to get some paltry documentation created by the developer AFTER we have asked for it and AFTER we have had to spend significant time trying to decipher their code.

What this translates to is high costs and time delays to you whenever you have to bring on new development staff. This happens when you grow. It happens when you need to let someone go or they leave. It happens, eventually. You should be prepared.

The sad thing is that developing the documentation isn't that difficult and it saves lots of time and money and avoids confusion and mistakes by the development staff.

We put together a small set of comprehensive documents that are both simple and easy to follow. It is like the architectural plans you get from an architect for a large construction project. These documents are critical in making sure the structure is built correctly. It also speeds up the construction and helps the project manager dole out tasks and monitor progress.

In short, these documents are critical in the success and efficiency of build and are done within that three week Analysis and Design. They improve the success of the build and lower costs and risk in the future as your development team changes.

Project Plan - Who, What, When and How Much

Also part of our three week Analysis and Design, we put together a detailed project plan for our customers. This plan maps out what individual tasks need to be done. It allows us to then assign tasks once build begins so everyone knows what they are responsible for and so nothing is missed. And it tells you how long the project will take and how much it will cost.

Unless you are working on a very small project, without a good project plan it is impossible to tell how long something will take or how much it will cost. Developers will try to estimate and sometimes they will be right but most often they are not. Developers are notorious for going over budget and taking too long. Quite often this is simply because they pull numbers out of their butt. They are not sure of everything they will need to do to complete the project because they haven't mapped it out. So they either under estimate because they left out critical tasks or they take their estimate and multiply by 4 or 10 which leads to gross over estimation. Regardless, it isn't accurate or reliable.

As a rough rule of thumb, any project over $10,000 should have a detailed project plan to ensure nothing is missed and keep the project on time and on budget.

With good architectural documentation, assembling a thorough detailed project plan is pretty straight forward. We provide this as part of the 3 week analysis and design process. It isn't difficult to do. Without it, the build is chaos and your time line and budget are at risk.

Your Path for Success

I am always surprised by how many people think that some initial preparation, documentation and a good project plan are considered too much overhead and not worth the time. The simple truth is that if you don't do a certain amount of this your project is highly likely to fail. At the very least, if you don't scope out your project sufficiently, you will probably build the wrong thing the first time and have to completely rebuild it a second time. This means double the cost and double the time to get it right.

Doing a good job with your analysis and design, getting good documentation and putting together a solid project plan doesn't take very long. If you find it taking more than a few weeks and you are focused on getting it done, you should probably consider breaking the project into smaller chunks. You may be making that initial project too complex.

Most software projects fail. Are you willing to risk failure on your next software project?

The Future of Software Development

Sat, 03 Sep 2011 16:00:00 GMT

The Future of Corporate IT

In the software world, we live in the wild, wild west. Software development is hardly more than a handful of decades old and has only gained the attention of non-techies in the last 20 years. The software development world is fraught with people building applications by the seat of their pants. Failure is the rule, not the exception. But it is interesting to see how the world of software is gradually changing. Standards for coding practices, higher expectations by product managers, greater demands by end users and government regulations are making an impact.

We are starting to tame the wild west of software. We have a long way to go but there is some progress.

Sow what is going to happen to software and how will that impact businesses and the people who manage them? Probably the best answer to this is to look at similar well established industries. While there are some differences, there is a great deal we can learn by turning our attention to the construction industry (office buildings, homes, bridges, dams, etc.).

So why use the construction industry as a model for what is to come in software?

The construction industry has been around for 1000's of years, is well established and disciplined. The software industry is very young and needs a role model to help determine the best path for it as its industry matures.
Construction is focused on building new things, often custom tailored to each customer. The same goes for software development.
Construction is not cheap. Neither is software development.
They provide professional services (architects, inspectors, project managers, etc.) done by high paid and highly trained individuals. In many regards custom software is even more dependent on these highly trained individuals.
They provide an on-demand work force that comes and goes as the client needs. Companies need large construction projects done in spurts. There is no real steady stream of work to keep full time employees busy. Companies do NOT hire their own construction crew, purchase their own bulldozers and cranes or take on the responsibility to keep these people busy on a regular basis. Rather, companies hire the maintenance and management crew who need to be there to support what they have. In software, the maintenance crew are called system administrators. Software is heading this direction and fewer companies are keeping the development staff on board full time but are keeping the administrators.
The majority of construction utilizes modular or pre-built components that are then assembled in a way specific for that project's needs. Today, the majority of new software starts off by importing pre-built libraries which helps the development crew focus on what makes the project different rather than having to reinvent the wheel.
Successful companies focus on what they do best. They don't do construction or software as their main focus. It is much more productive and more highly successful to bring in outside experts to get the job done than to try and become an expert in software as well as the industry your business is already in.
Construction is heavily regulated by the government. This is for quality and safety reasons as well as customer protection and many other reasons. The same is becoming true for the world of software. HIPPA regulations, PCI compliance and Sarbanes-Oxley are among the regulations that are starting to affect the software world. Adhering to these regulations can become a full time job. Companies need the expertise of another firm that understands these regulations and rules.
Construction companies can be held accountable for their work, are expected to carry insurance and are also expected to get things done on time and on budget. It is much harder or in some cases impossible to impose this on an employee. If the employee screws up or doesn't get the job done as expected, the best an employer can do is fire them--but the company is still out the money. For this reason, companies like bringing in outside firms to mitigate the risk. The world of software has the same perils and companies are starting to see the benefits to budget, time and risk by bringing in an outside software development firm.

Traditionally, companies have built up their own software engineering groups, hiring architects and software developers to build software for them. But in the construction world, what company brings in a full time architect as an employee, hires their own construction crew or purchases the equipment necessary to do the job? Unless they ARE a construction company or their industry somehow revolves around construction, the answer is almost none.

So why do companies still insist on having their own internal software group? This is akin to having a company within a company. Worse still, it means the business needs to be great at software as well as great at what they sell. To top it off, software is getting more complex and difficult.

Companies that deal with construction almost always outsource the design, architecture and the build of the project to another firm. They do often keep on staff a project manager (someone who is well versed in the business needs and can evaluate, select and manage the outside firm), facilities manager and maintenance crew. Sometimes these functions are outsourced as well, depending on the amount of work required. But they (almost) never hire full time architects or construction crew.

The software industry is slowly shifting this direction as well. Larger and larger companies are beginning to outsource more and more of their software projects. I am not talking about overseas outsourcing--just outsourcing to other companies regardless of where they operate.

Gradually we will see that companies will begin to only hire the business experts, project managers and support and maintenance staff. They will keep the people who:

Understand their specific business and how they uniquely operate within their industry.
Have enough work to keep them busy on a full time basis.

So what are the advantages of hiring an outside company?

IT isn't what those companies do, it isn't what they are best at.
Technology companies bring in knowledge from the outside - new ideas and techniques.
It creates a more competitive environment to help drive down costs and drive up quality of service.
Outside companies are more easily held accountable to time lines, budgets and deliverables.
Easier to ramp up and down as needed.
The world of software is getting more complex and it takes a full time effort to keep up with the latest technologies and best practices.

Smart companies and managers are beginning to see the value of leveraging outside development firms. We are seeing more and more customers who are turning to using our services even though they already have their own internal software development shop. And we expect to see more of it.

As for the software developers who fear to loose their jobs to companies like ours, never fear. The future for developers lies in working for software engineering firms. And a bright future this will be! It is much more fun for a software engineer when they work for a software (or at least a high tech) company. There is more variety of work, they get to use more of the latest technologies and they get to work with more people who have similar interests and profession.

All in all, the future looks good for everyone. As we move more toward the use of software engineering firms for those big software projects, employees will have grater capabilities and job satisfaction, and companies will get better software at a greater value to the company and at a much lower risk.

Writing FUBAR - What the Hell are Programmers Thinking?

Sun, 21 Aug 2011 15:00:00 GMT

Writing FUBAR - What the Hell are Programmers Thinking?

When I first began learning programming, I saw a lot of examples that looked like this:


int foo = 5;
int bar = foo * 2;
if (foo > bar) {
    System.out.println("You've been foobared!");
}

First let me say that this is the FIRST and LAST time you will see me write code like this. Coding like this is ridiculous. No good programmer writes code like this in the real world. It has somehow been adopted as a standard and acceptable way to teach new programmers how to write code. Unfortunately it is a very bad practice.

Why is it bad practice? Let me give you some reasons.

First of all, let's look at what foo and bar really mean and where they come from. The terms have had a little of a varied origin but in essence they are general purpose names. They are used when the meaning of the variable, function, etc. is not important to the understanding of the example.

But this is not how we program and it is not conducive to students' understanding of new programming concepts. In programming, everything has a meaning. And the meaning of the variables, functions, classes and other entities IS important. These generic names can actually lend confusion to the example as the programmer trying to learn the concept struggles with the code because it has no real world context. This context helps ground the student so they can look past the names and to the real substance of the example. I have seen all too often a new programmer get lost in an example like this because it lacks meaning - it is too abstract.

If you have a military background you probably already know an acronym that sounds similar. FUBAR means f**ked up beyond all recognition (or repair). Personally, I don't want my code being though of in this manner and I don't want anyone working for me that wants their code being unrecognizable either.
It isn't practical - no quality programmer writes code like this in the real world. Typically, use of generic names is considered amateurish or simply just bad practice. When people look at code like this they don't understand it and have to spend a great deal of time digging through it in order to determine what it is doing and if it is operating correctly.
Code should be human readable and names should be meaningful. This is of great importance because the person who wrote the code is inevitably going to hand it off to someone else in the future. Unless the application or chunk of code is thrown away, you will have multiple programmers have to read and possibly change or enhance the code. Make sure it takes as little time as possible for someone new to understand what is going on or they will waste a lot of time just trying to understand what the code is doing.
Often programmers think it is funny or cool to write code this way. Being funny, cute or somehow "cool" gets in the way of getting the job done. It is childish and demonstrates a lack of professionalism. Programmers should keep this type of behavior at home and out of the office. I am not trying to take the fun out of it. I am just saying that this behavior works to the detriment of others and can cost the business. By all means have fun but don't create problems for other team members.
If you are teaching, remember that students should learn how to code in the classroom the same way they will code in the real world. People mimic what they are taught. If you teach programmers to write foo and bar, they are likely to carry this type of practice over to the working world (at least until they are corrected and learn how to write code properly which they should have done in the classroom).

Just how hard is it to create real world examples? They don't have to be amazing works of software engineering, they just need to have some sort of real meaning. Yes, it will take a little effort but not much. And if you run short of ideas, just Google it. There are bound to be some great examples that have some real world application.

Teachers teach this type of dribble. But why? I think this comes back to the point above that they are attempting to take the student's attention away from the variables, functions, etc. that are not the point of the example and move focus toward the concept they are really trying to teach. But a good programmer likes to have context for the example. They see more than just the simple mechanics of the code and into the real purpose of it. When you use generic names you sanitize the code to a point that it ceases to be meaningful. Then it becomes more difficult for students to take the example and apply it to a real world situation because they begin to be distracted by questions like "What is this foo and bar thing anyway?"

So what are the principles to keep in mind when writing code (especially examples to teach students)?

First, find a real or at least close to real world example. Yes this takes a little more work than coming up with some generic meaningless code snippet. However, it will help new programmers put the code into context and will even make it more interesting. Academic types tend to love this more generic approach and if you are trying to create some sort of reusable abstraction it can be a good academic exercise. However, most people don't think this way and need real meaning. ("Meaning," am I using that word too much yet?)
Use names that have meaning (there is is again, let me use it some more) and lend to reading the code like it were a book. This is very important when adding new programmers and swapping staff on and off a project. If you are an employer you know you WILL have people come and go in the business and you WILL have to put new developers on old code.
Make sure you have peer review sessions. This is where one programmer reviews the code of another programmer. This is an excellent exercise for finding readability problems. It is not uncommon that a programmer writes something they think is readable but is hard to understand by another. It happens to even the best of us. It is also great for finding bugs and helping programmers share ideas on how to write great code so there are benefits beyond just checking readability.

What if the code a programmer is writing is generic or abstract?

First of all these abstractions still have names that have meaning within the context of the abstraction. Use those names.

In the event that you have general temporary variables like array indexes, it can be useful to follow industry standards. For example, it is well understood by developers that the letters i, j and k represent array indexes so using those can be acceptable. However, it is still better to use meaningful names like personIndex, propertyIndex and employeeIndex. I have seen (and even made the mistake of using them myself) generic names like i, j and k used and then the programmer gets them mixed up and uses the wrong one causing bugs and confusion. Use of meaningful names helps prevent these accidents.

When you write code for a living / for money, make sure you approach it with a professional attitude. Write it with meaning within the context of your application or library.

Here's a dirty little secret: Programmers hate to write documentation. What I have found is if you use meaningful names and write code so that it almost reads like a book, you don't need very much documentation for other programmers to be able to understand, use and maintain that code. However, the more generic or abstract the code, the greater the amount of documentation must be written.

Tell your programmers that unless they want to write lots of documentation, they should make their code easily readable, simple and easy to follow. They will be eager to write easy to read code.

When you teach people to write code, expect them to be learning because they intend to do it for a living. There are students that like the academic exercises and understand the generics or abstractions. But most people struggle with them. If you want to really teach effectively, create meaning and use names that fall within the context of that meaning.

As for employers, when you hire someone to write code, make sure they take the professional stance and write code that is easy to understand and maintain. It is an unfortunate fact but well over 90% of the code written by programmers, whether for small projects or for fortune 500 companies, is void of or contains little or useless documentation. Programmers hate to document and businesses don't like paying extra for the effort required to write that documentation.

Hopes this helps you become a better programmer or educator.

Happy coding!

The Matthew Effect

Tue, 09 Aug 2011 13:00:00 GMT

The Matthew Effect

"For everyone who has will be given more, and he will have an abundance. Whoever does not have, even what he has will be taken from him" (Matthew 25:29)

We have all have heard of "The rich get richer while the poor get poorer." This holds true whether talking about rich in money, rich in knowledge, rich in friends, or just about anything else.

What we have builds upon itself. At first just about whatever we do takes a lot of time and effort. Over time, however, it gets easier and easier. You gain knowledge on how to do things better, get systems into place which do the work for you, come up with efficient processes to do things faster and more reliably and create strategic alliances with others who augment your capabilities. As you continue to work you do more, better and faster.

On the opposite side of the spectrum is what is commonly called the "downward spiral." We see this with the poor and uneducated. They have not the money nor the knowledge on how to manage their lives.

One example of the downward spiral at work is in how the poor attempt to get rich. This typically takes the form of get rich schemes or the lottery. The plain fact is that these courses to trying to get rich almost always result in a lighter pocket book. On the incredibly rare chance that they pan out, the person who does get rich has money but quickly loses it because they never learned to manage their money. In fact, most people who win the lottery or sweepstakes end up worse afterwards because they spend themselves into great debt and lose it all. Regardless, the fact that they participate in these ways to quick and easy wealth show they lack the knowledge of what true wealth is or how to manage their money. That means they lack the knowledge of money they need to retain and grow the wealth that has fallen into their lap.

The perpetuation of ignorance is another example of the poor (this time in knowledge) remaining or becoming poor. Quite often those who do not have knowledge do not know how to defend their beliefs. When these beliefs are challenged, the typical response is to get defensive. It is not to engage in intellectual discourse and learn but rather to stand their ground and refuse to hear what the challenger has to say. The more ignorant the individual, the more defensive they can become. Meanwhile the highly educated seek out knowledge and are not as often put into a defensive posture. Highly educated people tend to like attaining more knowledge and feel they can better hold their own when challenged. As a result they are more often open to listening to others and learning more.

When we are young we are taught that we must be perfect, that mistakes are bad and that we are bad for making those mistakes. Nothing could be further from the truth. No one is perfect and we learn best by making mistakes. But when we fear mistakes, we also fear challenging our skills. Without the challenge being met, we do not gain more knowledge and skill from trying and making mistakes. So the people who keep trying grow their skills and are encouraged to seek out more practice to hone their skills while those who have weak skills often are afraid to spread their wings and never gain or grow the skills they need to perform well in society.

One of the biggest problems I have seen plague the more intelligent people I have had the opportunity to work with is how they never seem to have enough time to do what they need to do. These are people poor in time. The less time they have, the more they rush around trying to catch up and get things done. These are often the people who work the hardest. They are also the people who get very little done relative to how hard they work. They are so caught up in getting things done they never stop and take a look at whether they are doing the right things and whether those things are being carried out in the most efficient way. This is a problem that plagues our Western society. People are in such a hurry, doing this, doing that, and they so rarely see that most of what they are doing is needless busy work which just serves to make them feel like they are getting things done.

So what do we do about it?

The first thing you need to do is determine just what your are poor in in your life. Do you have very little money? How about education? Skill? Time? Something else?

Once you identify what you seem to lack in your life, you need to take a step back and take an objective look at what you are doing. Then look at the people around you who do not seem to have this problem. What are they doing that you are not? What are they not doing that you are doing?

This is much like how when we were children we picked out people in our lives that we idolized. Sometimes these were fictional characters but when they were real people, we had a real template for modeling our lives. It is funny how we loose this fascination with idols as we grow older. It is like we have reached a point where we are too old for that ridiculous stuff. But having an idol or better yet multiple idols to help us model our lives after helps us put a real world direction to our path. If someone has achieved something we wish to achieve, who better to model ourselves after?

Of course we don't pattern our whole life after our idol. Personally I like to find a number of people I wish to be like in some way. I like to pick out a diverse group that has one common quality I wish to emulate in my life. I then look for the commonalities in all these potential idols. This helps me see what I do and do not want to incorporate into my life based on what I see these others do.

You can also use this in reverse. Find the individuals which you want to be very different from. What are these anti-idols doing? That will help you see what you do NOT want to do.

Improving yourself takes time. Don't rush it. And keep dedicated to making yourself better. If you get into a hurry you will likely get discouraged and stop working toward the improvement and it shall be taken from you. But if you keep building up on what you lack, over time it will begin to come in in abundance.

Work smarter and not harder. Keep reflecting on what you are doing and what is and is not working. Hard work may be required at first but over time you should see ways to improve that require less and less effort. Keep taking the time to reflect and come up with better ways to attain what you are after.

Look for mentors (educators, business mentors, local foundations, apprenticeships, internships). There are a lot of people out there who will happily share what they know to people who are passionate about what the mentor has gains expertise in.

Also seek out industry experts. These experts may have written books or provide training. They may be willing to provide consulting hours to help you do what they do. This can save you years of effort and help prevent you from having to make costly mistakes.

However you do it, know that you have to build and keep on building. Look for success and emulate that success. And remember that over time you will begin to grow faster and faster, it will become easier and easier and you too will have the qualities in life that others enjoy.

If You Fail to Plan, You Plan to Fail

Fri, 29 Jul 2011 14:30:00 GMT

If You Fail to Plan, You Plan to Fail

Back in the days of grade school, we were all taught to put together an outline before writing our paper. I remember it well. And I think most of us hated it.

The raw truth of the matter is that we all want to get things done. We don't want to waste a bunch of time on frivolous tasks. "Let's get to the meat of it!"

But jumping in and starting to work before we really know what we are doing is inviting disaster. Without at least a little prep work, we really don't know what we are trying to accomplish let alone know what we need to do to accomplish it. All too often we get impatient and jump right in.

But what were to happen if you decided to go on vacation and you just loaded up, jumped into a car and took off? Would you forget something you need like your bathing suit or coat? If you don't know where you are going you would have to load up everything you could possibly need. Even then you would likely forget something. You would definitely take way too much.

Before we take off on a simple 2 day or even 2 week vacation we at least need to know where we are going, what it will take to get there, how much it will cost and how we will get back. We do at least a little planning before just taking off. Some people plan every little detail while others like to take it loose and fancy free. But we all do at least a little ahead thinking.

(OK, so there are a few thrill seekers out there who want the excitement of the unknown, the uncertainty. That's great for fun if you like that sort of thing. But the vast majority of us want to know roughly where we are going and what we will be doing so we know the vacation will be fun.)

Planning for Success

When you plan ahead, your first set a target, then you determine what the steps are to get there. Your target may change over time and that is OK, but without at least an initial target it would be like jumping in your car and taking off in some random direction. If you wanted to sun bathe on the beach and you head toward Alaska, you are going to be disappointed when you arrive.

The target is where you want to end up. This target should be somewhat ambitious but still reasonable. With enough hard work you should be able to attain your target. And the target needs to be a somewhat short distance away. Sure you can set longer term targets but the world changes at a relatively fast pace and thinking too far out is more of a dream rather than an attainable target. Definitely think long term but set your next targets close.

Notice I do not say "Goal" here. While it may not exactly be by definition, in most peoples' minds a Goal is a fixed thing you are trying to achieve. But a "Target" is more flexible. We have all heard of a moving target but no one talks about a moving goal.

Targets change over time. As you approach your target it will likely move so plan to move with it. If you set a series of targets, the further out each target is the more likely it is to move as you approach it.

Analysis Paralysis

There is such a thing as too much planning. Sometimes people get paralyzed by trying to perfect their plan, trying to make sure there is no possibility for error. The sad fact of the matter is that reality is not perfect and that no matter how much you plan unexpected things happen.

Perfection comes at a very high price. Generally speaking, about 80% of your plan can be ironed out with only 20% of the work. That last 20% though takes a lion share of the effort. By the time you have perfected your plan you could have simply put something out on the market and tried it out. Trying it out on the market would give you greater returns anyway.

When you work on your plan, set some deadlines. Decide when it is going to be good enough to put the plan in motion and try it out.

Be prepared to make mistakes and learn, then try again. Failure is one of the greatest learning tools you can have. Mistakes are wonderful teachers. Do NOT be afraid to make mistakes but instead embrace them as ways to make you better. The only time mistakes are a problem is if you keep making the same mistakes over again and again - it means you are not learning how to do things better. Really look deep at your mistakes facing them head on and use them to do better the next time.

When Have You Planned Enough?

The real trick is to determine how much planning is enough planning. In general I like to have planning and execution cycles range between 1 week and 6 months with the majority of these cycles at around 3 months.

Your planning cycle should depend on the amount of work the plan and implementation cycle will entail. If you do very small bits of change to what you already have you can get things done in just a week or two. If you are creating something new or making very large changes then 3 to 6 months are in order.

If you find that the effort will take over 6 months you may want to consider breaking your plan up into several stages or iterations. Get the first iteration completed before moving on to the next. Recall that your target moves and the further out it is the more it is likely to move. If your plan and execution of that plan takes too long you may find it has moved so far that much of the work you have done has taken you too far off that target and is wasted. Additionally, shorter iterations will allow you to deliver change sooner which means you reap the rewards much more quickly.

Avoiding Costly Mistakes (how to cheat the right way)

We all fear making big or damaging mistakes. From the time we were kids we were taught that we must do things perfectly (get that 100% or the A+) and that mistakes are bad.

While mistakes are good for us and teach us best, there is a great way to minimize your mistakes and improve the overall result: bring in someone who has already made those mistakes and knows better.

This is why you often hear advice from successful business builders to hire the experts. Experts have been there and done that. They know how to navigate the problems that could come up because they have already done it themselves, often many times. They know not only how to avoid the mistakes but how to avoid them well and do it easily.

The best time to bring in the experts is when you have never or very rarely ever done what you are preparing to do.

This is how we help our customers. We provide expertise and decades of accumulated experience to help make sure our clients set effective targets and hit them dead center. We also assist with determining just how much to plan to help avoid analysis paralysis. And we help reduce the length of the iterations which help reduce up front costs and speed up the time to start making or saving money off the endeavor.

We provide software and software integration solutions for customers. We use and help match up our clients with other experts such as designers, marketing and sales gurus and hardware specialists - people we often use ourselves (we practice what we preach after all).

If you are interested in how we can help you, contact us today and we would be glad to meet with you in a complimentary consultation to evaluate if we are the experts you need and if so tell you how we can make a difference to your success.

To Cloud Or Not To Cloud

Thu, 21 Jul 2011 19:00:00 GMT

To Cloud Or Not To Cloud

The Cloud

It's the new buzz word.

In my last post I discussed Bleeding Edge versus Cutting Edge technologies. When a new technology suddenly becomes all the rage, you are beginning to see that technology starting to push from the bleeding edge into the cutting edge. It is no different here.

People have been talking about "the cloud" for some time now. Recently both Apple and Microsoft jumped on board with their own cloud. Amazon has been doing it for a long time now.

But just what is this "cloud" anyway?

According to Wikipedia, Cloud Computing is "using multiple server computers via a digital network, as though they were one computer" (See Details Here).

But the definition has really been warped. Now when people talk about "being in the cloud" they usually mean that they are using, at least in part, applications that reside on other computers on the internet. Simply stated, saying "the cloud" is marketing speak for "on the internet".

So what is the big deal anyway?

While it may sound as if marketing is just trying to pull the wool over your eyes, there really is something different about the use of the internet that people are trying to communicate when they say "the cloud". What people are trying to emphasize is not some new-fangled technology, though new technology is making it easier and better, but instead it is a new way of using the internet.

Back in the early days of computing users had to sit down on dummy terminals which plugged into a very large, centrally located computer. Computers were too big to fit on a desk or even in someone's office. They were also too expensive to purchase a computer for each individual.

This centrally located computer made it easier to manage allowing staff to support and upgrade everyone by managing a single computer. It also helped take large expenses and distribute them across many users increasing the value for the dollar. The problem was that you had to physically connect your terminal to the mainframe. This usually meant computer users had to go down to a computer center which was less than convenient. It also meant computers were not easily available to the general public and usually restricted to large companies or educational institutions.

Once the personal computer became small, easy and affordable, there was a shift away from the mainframe computers. Now people were freed up to have a computer in their home or office. They could install whatever software they wanted. And they were not restricted in use based on what their company or university policies imposed.

When the internet started to become in wide use, computers began to become interconnected again. At first, the internet was a large combination of individual computers communicating seemingly at random as needed.

The new problem was that people began to take on the responsibility of setting up and maintaining their own computers. From installing software, troubleshooting problems to dealing with viruses and hackers, individual users were required to become somewhat technical. And you had to install and continually upgrade your own software which wasn't exactly cheap.

Over the last several years we have seen a new shift. This is the shift to "the cloud" everyone is talking about. In essence, we are beginning to go back to the old mainframe model. But this time it is better.

How is it better? First of all, with the wide reach of the internet, the vast connectivity and wireless technologies, you can get on "the cloud" from just about anywhere. Secondly, you can do it from your personal device. This gives you the freedom and control that was never a part of the mainframe.

The exciting part about "the cloud" over the individual personal computer is that of the time and cost to the individual. As the internet speeds improve, dead zones disappear and more software is made available as an online service, our personal computers and devices become simpler and cheaper. More of the raw processing power is used to servers. More of the security and protection from hackers and malware is placed on the service provider. And the less power is required of your device (which translates to cheaper, smaller, lighter weight and less power usage).

But while we keep hearing about the greatness of the cloud, it is still a Bleeding Edge technology. There are some services that work great like e-commerce web sites, online news, video services and online backup services. But most of the best technologies out there are either really simple user interfaces or services that still require software be downloaded and installed on your own computer.

To be a pure cloud application (pure being a somewhat subjective term here), you would want the whole application to run on a server while the only thing that runs on your computer is a simple user interface that interacts with that server and allows the server to do all the work. We see this with some online games like web apps (Google Docs and web stores), MMORPG's (World of Warcraft and Everquest) and Flash based applications (Gliffy).

The thing we hear probably a little too much of now is how clients want to be a part of "the cloud." To an extent I do agree. But we must be careful here. There is a reason most applications we use today either not cloud based or only partially cloud based and still require software to be installed and run on your own computer. Understanding the limitations of "the cloud" is important in making sure you stay on the cutting edge and don't slip over into the bleeding edge.

The first and probably most important reason most applications are not purely cloud based is speed. Google is desperately trying to expand the new faster internet connections throughout the US. But this takes time. For now, many of the purely cloud based applications are painfully slow because the internet is slow. Yes, it is faster than it used to be and it is getting faster. But it is also much more heavily taxed by increasing demand.

The second is that the technologies to help deliver pure cloud based services is not quite mature. To deliver an application to any device requires that application developers write their software three or four times. This means instead of writing one application, we have to write three or four applications thus multiplying the cost by three or four times. Additionally, the software frameworks for the different platforms is somewhat limited. On top of it all, the standards for how the frameworks are slow to be defined and then adopted (this is especially true with web applications - what works on one browser doesn't work on another or what works on one operating system doesn't work the same on another).

Another change that is occurring but still a bit slow to be adopted is the acceptance of this new model by consumers. Some of us still like to work "off the grid." Others want to "own" their software and are not comfortable with a "leasing" model most cloud services provide. There are privacy and security concerns as well.

There is no doubt, "the cloud" is slowly moving from Bleeding Edge to the more main stream Cutting Edge. It is an important part of our future in computer and device usage. And it promises to provide a much richer and more efficient experience for users. But in many regards it is still Bleeding Edge. So if you want to cloud enable your application, be sure to look at the options. You don't have to go pure cloud - quite often a mix of approaches can provide the best of both worlds merging convenience, low cost and ease for users.

Bleeding Edge or Cutting Edge

Tue, 19 Jul 2011 14:30:00 GMT

Bleeding Edge or Cutting Edge

In today's fast paced world, especially within the technology sector, everything is changing on a daily basis. What was new becomes common place and what was common becomes old and out of date.

In order to keep up, we need to be constantly improving ourselves by playing with, learning about and incorporating into our lives and businesses new ideas and technologies. If we were to try and keep up with everything, we would quickly become frustrated and find it is next to impossible so we must choose what to focus our efforts on. But just what should we choose then?

Of course the first choice should be on what is most relevant to you and your life. Sometimes this is an obvious choice. Sometimes what looks irrelevant could be relevant and you just don't know it.

What I like to do in these circumstances is to make my best decision and focus on what I think it the best use of my time but keep an ear open for new possibilities. I then surround myself with people who love to try out new things, especially when their interests are different from mine. Then I chat with them on a regular basis and inquire into what they think are the upcoming new ideas and technologies. I don't look into everything my colleagues bring up but I do discuss their opinions and delve into what they think is important so I can better decide what new concepts, products and services to dig into myself.

Most people do this as well. Since we cannot look into everything, we must pick and choose. And as long as we are open minded and mingle with people with different ideas and experiences, we can't help but be exposed to other options out there which can improve our lives.

But what I find a lot of people have difficulty with is determining when to dive into something new. Do you dig into it as soon as it first comes out, before anyone else even knows about it? Or do you wait until it is all the rage and spend your time on it then knowing that if everyone else is using it, maybe you should to?

The answer to this depends upon what you are doing with the new concept, technology, product or service.

Bleeding Edge vs. Cutting Edge

When something new first comes out, when almost no one has tried it out and when it is still new and somewhat untested, I call this the Bleeding Edge. When you dive into a new technology that is on the Bleeding Edge, you will find it takes a lot more blood, sweat and tears to really understand and incorporate it into what you do. For technology, the bleeding edge means it is still buggy and somewhat unreliable. This is where, when you use the new tool, you bleed a little. You pay a small price for trying out something that is not yet proven or perfected.

Over time, if a bleeding edge technology sparks enough interest in the early adopters, it can move on to be a cutting edge product or service. This is the time where those who adopt the new technology can carve out a way of living or working with a well sharpened knife. Like any tool, when it is new and well honed it is at its most effective. It is well documented or understood and the early adopters have helped work out the kinks so it has few if any real flaws to cause you problems.

Eventually that tool tends begins to become dull. There are things you can to do resharpen it and it can continue to be useful to you. However, adoption of a technology after it has passed its cutting edge stage is typically low impact on you and your business.

When To Adopt What?

If you are an industry leader or a trend setter, it is important that you pursue technologies and concepts in their early most stages. This is the bleeding edge. If you are an industry expert giving advice to others or the person people turn to when they want to know what to adopt next, you need to be ahead of the pack and it is worth the price to bleed a little.

Bleeding Edge adopters are generally the people who blog and write books about the upcoming trends. They are the people who also try to beat the competition to market with new products and services. You must take care though if you try to build a business around bleeding edge technologies. History has shown that the businesses first to the market with a new idea tend to be the ones that fail while those a little later to the game are the big successes as they build off the mistakes and pay a lower price to create their products and services.

If you are more interested in adopting technologies when you pay the lowest price for the greatest gain, you will be more interested in adopting new ideas and technologies once they have matured. This is where you will be more likely to adopt during the cutting edge stage. You have let others bleed for you as they have documented and perfected how to make the most of this new technology.

This is usually where most people want to be. It has the potential for the greatest gains without having to bleed for it. We often say that we look to be cutting edge, not bleeding edge when evaluating new tools, products or processes. We want to get the biggest bang for our buck.

Sometimes, however, a technology my just not be very relevant to you. The gains from this new and innovative product or service is just not going to help you much. This is where you may never adopt it but if you do it will be once it is common place and the rage has died out. It can become useful to you though as, at this stage, it is generally very low cost to adopt. So while the benefit may be quite small, if the cost is small enough it could be worth it.

What you choose to use and when ultimately depends on your situation. However, always keep an ear open, think of how you might be able to innovate your business around the next rage. And remember, there is a time to be bleeding edge, a time to be cutting edge and a time to wait until the rage has gone. So choose wisely and choose what best fits you.

Simplicity Rules - Keep Focused on a Single Theme

Tue, 12 Jul 2011 14:00:00 GMT

Simplicity Rules - Keep Focused on a Single Theme

Over the years I have been involved in the design and construction of dozens of applications. What I have found is that the application begins from a simple concept but quickly grows to a large and complicated machine. By the time clients come to us, they typically have an almost endless list of features they want included. At first, these features are mostly "have to have." But as we go through the requirements and feature list with our clients we often find that there is entirely too much to be included in the initial application and many of those "have to haves" just have to go.

For one, they can't afford to do everything. Everyone has a limit to their budget and has some time line for project completion.

Additionally, the complexity of the application tends to grow exponentially with the increase in number of features. This means that as they double the features, they quadruple the complexity. Complexity leads to increased costs and time to build and test. Also, the more complex an application is, they more bug prone it is and the harder it is to find and remove those bugs without introducing more bugs.

The first release of an application is also one of the most critical steps in building an application for a business. If it is not done right, the business effort can collapse and the project will fail immediately. If you put all your eggs in one basket, you won't have any ability to change and try again once you learn about the short comings in your application.

Do not be so presumptuous as to think you will get it right the first time. You won't. You need to be prepared to put something in front of users and find out there are things you did not consider. It doesn't matter how much design and usability testing you do, you WILL miss things. Be ready to build a second and even third version before you get it right.

Recently I read an article by a well known writer who has been writing professionally for decades. In this article, he suggested that whenever you write, you keep the writing about a single theme throughout. Everything in your article or even a whole book should revolve around a single idea.

Designing your application, especially in the first phase, should also be focused on a single idea or theme. This focus will help ensure the one thing you are trying to do will be done well. It will help users follow the application and will also help focus on your niche market. After all, that is what a niche market is - a focused segment of the market.

Gather your requirements and feature list together and bounce them against the main idea of your application. Which features match and which do not. Discard or at least set aside those requirements and features that do not service your core idea and keep only those that support or drive the main idea.

Next, look at your overall design. How does the design drive a user to the main idea? Are there steps that are extraneous? Quite often we work in steps, try to capture additional data or put in extra features or processes that act as obstructions or distractions from the main purpose of the application. These must be removed from the initial application. If you just know this feature or that step will need to be there eventually, put it on a later phase list but do NOT do it now.

One of the great things about building software, especially when it is a web application or service oriented (SAAS), is that you can always improve it later. And you can keep improving it whenever you want, however often you want, with little concern about upgrading users. If you are pushing software updates to users (mobile and desktop applications are good examples), you have to be prepared to manage your updates a little more carefully but those can be done as needed too, with a little prep work.

The key is to find your focus and keep to that focus. This will keep your initial costs down and reduce the time to launch your application. Your application will also have a much better chance of appealing to your target audience and be easier for them to use. Then after getting feedback from the users and finding out what THEY want to see in the next version of your application, you make changes and additions that will strengthen your relationship to your customer and has a higher probability of capturing even more customers.