Brett Miller is the president of Custom Software by Preston (CSP). For more than 10 years, CSP has impressed clients with highly effective software solutions and teams of multi-talented software engineers.

A software development client should complete a thorough “due diligence” before selecting a developer for his critical project. Then, he must complete the finalization process by drafting and executing the legal contract/agreement.

Contracts attempt to define the responsibilities and duties of each party; however, people often overlook whether a contract covers certain risks associated with non-performance.

Take a look at the eight scenarios below. These tips can help your company cover its legal bases when contracting a software developer, or vice versa.


1. Time & Material (T&M) or Fixed-Price Contracts


In a “time and materials” contract, the client assumes the burden of cost overruns, whereas in a “fixed-price” scenario, the developer assumes this risk. Weighing the two, many clients assume they are ahead of the game by passing the potential for cost overruns to the developer. However, they but fail to consider that the developer must add that cost-potential into their fixed-bid up front. So in a fixed-price contract, the client pays the extra cost, even if it proves to be unnecessary.

Fixed-price contracts also have the potential to create disputes. Often, deliverables that were implicitly intended might not be included in the original project scope. Both parties should be very aware of what exactly is included in the project. Fixed-price means there is a fixed scope of work, unless additional moneys are paid.

In a time and materials contract, the developer gets paid on an hourly basis. The motivation to finish quickly may be diminished by the opportunity to bill more hours. In this case, the client takes the risk that the developer will prioritize his own desire to profit on the project.


2. General Note on Contracts and Non-Disclosures (NDAs)


Contracts and NDAs are legal instruments which establish the rights, duties and privileges of those who are a party to the agreement. These instruments protect both parties to the extent that they are willing to pursue them in a court of law.

Here is a simple rule of thumb, although I encourage you to also check with legal counsel. Unless the dispute is over $10,000, most attorneys won’t take the case. And even if they do, they usually keep one-third of any money they collect. It can take several years to win in court, and the problem is further exacerbated by the fact that the losing party may no longer be in business or have assets from which to pay. One last note, many contracts call for the losing party to pay the legal costs for the winning party, which can save you money if you win, but cost dearly if you don’t.


3. Advanced Payment – The Industry Standard


Many contracts call for advanced payments or retainers. Essentially that means the developer works on the client’s money, and therefore, the client bears the risk for the developer’s potential lack of performance. This is the norm in the information technology field. Very few developers will take money out of their own pockets to build a client projects (in the hopes that the client will pay).

An improvement to this model would be to limit the retainer to two week’s worth (or less) of development time/labor (weighing the progress of deliverables). Upon client acceptance, the retainer can be replenished for the next cycle. Sending a wire or paying via credit card allows for instantaneous payment. Client risk is bit more limited when using this approach.


4. Phased Payments – The Other Industry Standard


Some projects are divided into three or more segments. The first phase is paid up-front (client risk); the second is paid at some pre-arranged interval (equal risk); and the last payment is made upon project “completion and acceptance” (developer’s risk). In this scenario the last payment can be problematic to collect, as subjective issues can arise regarding quality and scope.

One minor modification to the phased payment method specifies that the developer finish the final deliverable in their own environment, to which the client has access for testing. Upon client acceptance, the final payment is made and the vendor transfers ownership of the application and all code to the client. This is a very solid, technique balancing risk.


5. Warning! Warning! Kill Switches


Some unscrupulous software vendors build a kill switch into their applications. In the event of a dispute (and the client refuses to pay), the vendor can remotely shut down the application. I recommend that your contract include language that prohibits this “extortion like” practice.


6. Disappearing Freelancers


Many IT Professionals have heard this story before: A company finds what appears to be a knowledgeable (and affordable) freelancer on the Internet. Initial contacts with the individual indicate great responsiveness. Payment is made, a few conversations take place, some small progress is shown — then all communication goes dark and the freelancer disappears.

I believe this most often occurs when, with the best of intentions, a freelancer takes on a project and finds out he bit off more than he could chew. He believe his efforts were substantial, but things just didn’t work out (in other words, “not their fault”). Even more important, as a freelancer he is simply not in a position to refund any money. It’s easier to disappear than to deal with the conflict, so he runs.

Freelance software developers do offer expertise, experience and cheaper rates due to lower overhead, but the clear risk is a lack of any substantial backing. Therefore, this model does have more risk for the end client.


7. Payment via PayPal or Credit Card Carriers


Many developers accept payment via PayPal, and some even accept credit cards. These credit carriers offer “dispute” mechanisms that allow the payee to challenge any charge which was not delivered as promised or described. This method should be encouraged by the client (even if they need to pay the credit card processing fees), as it provides additional protection.

Vendors have an opportunity to respond to any dispute. Carriers to a certain degree are arbitrators and if they receive enough complaints, a vendor’s account can be canceled.


8. Risk Assessment


Software development projects carry financial risk factors for both parties. These risk factors need to be considered seriously and should be discussed with an attorney. Clients and developers alike need to know what they are getting into and prepare for scenarios that don’t work out as planned.

Image courtesy of iStockphoto, OtmarW, Flickr, quaziefoto, slimmer_jimmer

More About: contracts, contributor, dev, features, freelance, law, legal, software development, Web Development

For more Dev & Design coverage:





Jonathan Goldford is a partner at JG Visual, an Internet strategy company that works with organizations to develop and implement their online presence. You can connect with Jonathan on the JG Visual Facebook page.

Sometimes as programmers, we forget that 99.9% of the population doesn’t care how a piece of text, a button, an image or a video ends up onscreen. Most people just care that it’s fast, easy to use and gives them the content they want. Otherwise, they get upset — and rightfully so. Here are three common mistakes we programmers make, and what we can do to fix them.


1. Forgetting About Conventions


Ever since they started using the Internet, users have been trained how to interact with a website. Therefore, they often get frustrated when websites don’t meet their expectations. Here are some examples.

  • They hover over an object they think is clickable, but become confused when they see an arrow instead of a hand pointer.
  • They click on blue, underlined text, but find it’s not a link.
  • They click on the logo in the top left, believing it will return them to the homepage, only to find it takes them nowhere.

Web design doesn’t always meet our expectations. However, developers and designers should always maintain certain rules to avoid user confusion. Here are three.

Clickable Elements Should Have the Pointer on Rollover
Everything clickable should switch to the hand pointer when a user hovers over it. You can accomplish this using simple CSS. The code would look like this

div:hover { cursor: pointer; }

Style Links Appropriately
Links should look different than regular text, and should be underlined within a page’s main content. If you really want to stick with convention, make them blue — research found users engage most with blue links.

Make Logos Clickable
The logo in the header of your website should be clickable, and should take the user to the homepage. This is pretty simple: Just wrap your logo in a tag.

<a href="http://www.example.com">
<img src="logo.gif" alt="Example Company" title="Example Company Logo" height="100" width="100" />
</a>


2. Creating Slowly-Loading Websites


Users hate slow websites. Studies have shown that 40% of users will abandon a website that takes more than three seconds to load. Here’s how to avoid common speed mistakes by new programmers.

Resize Images Outside the Browser
New programmers will sometimes use a very large image, let’s say 600 pixels wide by 600 pixels tall, but will set the height and width so the image shrinks to the desired size. They use the following code.

<img src="big-domo.jpg" alt="Domo" title="Big domo at the park" height="200" width="200" />

There are two problems with this method: First, the full image still needs to load. Typically, bigger image files mean longer load times.

Second, shrinking an image using the height and width attributes can render a photo awkwardly, causing the browser to display a photo not nearly as clear as it would be were the image sized 200 x 200 pixels.

To fix these issues, resize and compress images in an editor like Photoshop or Gimp. Then code the image like we did above. Try to use a tool like Photoshop’s Save for Web & Devices to further shrink the file size.

Load JavaScript in the Footer
Many programmers unnecessarily load all the page’s JavaScript files in the head tag. This stalls the rest of the page load. In almost all cases, except for JavaScript critical to user interface navigation, it’s okay to load script in the footer. Then the rest of the page can load beforehand. Try this code.

Rest of the page...
<script type="text/javascript" src="js/scripts.js"></script>
</body>
</html>

Load CSS Externally
Sometimes new programmers load CSS on each individual page using inline styles or an internal stylesheet. For inline styles, code looks like this.

<p style="margin-top: 50px;">Hi Mom!</p>

And for an internal stylesheet, you’d most likely see this code in the head tag.

<style type="text/css">
p { margin-top: 50px; }
</style>

You should almost never use CSS in the page that holds your html. Store it externally using code like this.

<link rel="stylesheet" type="text/css" href="css/style.css" />

There are two advantages to loading CSS externally: First, the user’s computer will save the external stylesheet to be used on every page, instead of retrieving the same styles over and over. This greatly speeds up load time.
Second, using an external stylesheet is much easier to maintain. If you need to change the font size of your website’s paragraphs, you’re able change it in one place, without having to access each individual html file.
Learn more about good CSS practices at CSS Basics.


3. Not Accounting for Potential Backend Changes


Most programmers nowadays are using a content management system like WordPress, Joomla or Drupal to build their websites. This is great because it gives website owners the ability to make changes and updates.

The problem is that a lot of developers only program for a website’s content at launch time. For example, at launch a developer may only create CSS styles for website headings 1, 2 and 3. What if two months after the website’s launch, the communications director decides to set some text to heading 6, since that’s an option in WordPress’s format? That decision would revert to the default styles of the browser since the developer never styled for it initially. Here is how to avoid this situation.

Include Styles for All the Common Tags
To make sure that the design of your website remains consistent with any backend formatting, programmers should include styles to handle the following html tags.

  • Body (<body>)
  • Heading 1, 2, 3, 4, 5, 6 (<h1>, <h2>, <h3>, <h4>, <h5>, <h6>)
  • Link (<a>)
  • Paragraph (<p>)
  • Address (<address>)
  • Preformatted (<pre>)
  • Strong (<strong>)
  • Unordered list (<ul>)
  • Ordered list (<ol>)
  • Quotes (<blockquote>)

It’s best to check the WYSIWYG that your website owners are using to make sure you have all the appropriate tags covered.

Basic styling isn’t the only opportunity for your website to break down. Also make sure to prepare for large image uploads and for copy/paste from Word. Although items like these can seem trivial, educating your website owners about how to add content can make all the difference.


You’re Smart, But It’s Hard To Remember Everything


The mistakes listed here have nothing to do with a developer’s intelligence. Like most jobs, things fall through the cracks, especially when you’re just getting started.

Do you agree with the items listed above? Are there any others we should have included?

Image courtesy of Flickr, …Tim

More About: contributor, design, dev, features, programming, Tech

For more Dev & Design coverage:





The Web Development Series is supported by Rackspace, the better way to do hosting. Learn more about Rackspace’s hosting solutions here.

When you think of web typography, CSS instantly comes to mind. And that’s great, because CSS is the primary option when dealing with the style/visual layer of your website.

However, when you hit a roadblock with CSS, take it up a level by using JavaScript (JS).

Open source JavaScript libraries can help you craft responsive web designs (a technique that optimizes webpage layouts for mobile devices), implement fun text effects and more. In this post, we will primarily focus on JavaScript libraries that use modern web typography techniques to underscore and promote current web design best practices.

1. Kerning.js

rackspace

The Web Development Series is supported by Rackspace, the better way to do hosting. No more worrying about web hosting uptime. No more spending your time, energy and resources trying to stay on top of things like patching, updating, monitoring, backing up data and the like. Learn why.

Image courtesy of iStockphoto, Punkle

More About: design, dev, features, javascript, typography, web development series

For more Dev & Design coverage: