PHP 5.3 is out and is moving from “a nice toy to play with” release into a production ready version of PHP. I for one am ready for this to happen. PHP 5.3 has some really great improvements that will empower programmers to do rock-star level stuff. Here are three things that I’m itching to use.

Name Spaces
I can’t think of a more wonderful thing to come to PHP. Right now I have to create class names that look more like paragraphs than anything else. Here’s a little (fake) example.

LB_ContentManagement_Helper_Validation_SpecialCharacters::ReplaceAmpersand($content);

In order to have an __autoload() function we need to have class names that also represent where the file is found. It makes for all kinds of goofy class names. I’m looking forward to the day when I can just state the namespaces I’m using and then call the class like this

SpecialCharacters::ReplaceAmpersand($content);

Late Static Binding
This is a complex issue with many implications. One of those implications is that you can now call a static method from a variable like so.

$className = "Users";
$methodName = "Login";

$className::$methodName("bob@domain.com","password");

Prior to PHP 5.3, this wasn’t possible. You had to instantiate the class, then call a public method to do the same thing. Now you can call a method outside of the context of strict inheritance. In the above example you could set a different method for different types of logins, such as an admin login vs. a site user. Not the most practical example, but it gives you an idea of what you can do.

Anonymous Functons
Anyone who has done anything with JavaScript will know the power of anonymous functions. They empower the programmer to create a function that can be used as a callback. Here’s an example.

function doStuff($arg1, $arg2, $callback)
{
    // do something with the arguments

    $callback();
}

doStuff("1", "2", function() { echo "we just did a callback"; });

In the above example, the call to the function “doStuff” contained an anonymous function. This was then called within “doStuff” when all the processing of $arg1 and $arg2 was finished. This methodology has been a life saver in JavaScript, especially with jQuery, and I’m glad to see its arrival in PHP.

These and other features are moving PHP forward. I can’t wait until PHP 5.3 is adopted as the standard so that these new features can be turned into great applications.

More minute methods to further improve your database performance

“Schema Busters” is a multipart technical overview of Database Design elements that you can implement when designing and accessing your database implementation. In this third section we will discuss several tricks and tweaks to consider when constructing your database schema and queries. While some of the proposed methods are fundamental and globally applicable, others are subject to a lot of debate since they are highly situational. Take the application logic into careful consideration before utilizing these methods since some of the proposed methods can actually work to the detriment of your system. The examples below are intended for a MySql implementation, but I am confident that similar issues can be resolved in a similar fashion for other database engines. With that said let’s begin with an extremely MySql specific concern.

MySql Storage Engines and the COUNT Function
While administering your database you may have noticed that MySql has two primary storage engines: MyISAM, which is good for read-heavy applications, and InnoDB, which is good for write-heavy applications. In general the two have similar performances with the one exception being how they handle the COUNT function. Before I begin discussing the benefits of using MyISAM’s meta-data collection, I would like to remind readers that InnoDB has considerable benefits when creating an insert/update heavy application which is common in several company intranet applications. Since a large majority of lifeBLUE’s projects involve front-facing websites wrapped around a back-end management utility, we frequently utilize the MyISAM engine over InnoDB.

MyISAM keeps an internal cache of table meta-data whereas InnoDB keeps no such cache. One of the values found in this table meta-data is the number of rows, which in turn means any COUNT(*) call has the potential of having minimal costs. InnoDB, on the other hand, has to read every entry row present in a table to evaluate a COUNT(*) call (which is about as effective as calling SELECT(*) on the table). The major drawback to utilizing MyISAM is the loss of InnoDB-specific functionality such as stored procedures.

Subqueries vs. Joins
For those who are unfamiliar with the terminology, Subqueries involve the embedding of queries in another query, most commonly in the form of SELECT statements, while a JOIN operation creates a temporary table that holds results from two different tables linked by an identical value in both tables. Two example queries with the same results are provided below:

• Subquery:
  SELECT d.Id, (SELECT alias FROM resources r WHERE r.Id = d.Id) AS alias FROM document d
• Join:
  SELECT d.Id, r.alias FROM resources r INNER JOIN document d ON (r.Id = d.Id) GROUP BY r.Id

A general rule of thumb is to replace correlated subqueries with joins. A correlation occurs when the subquery references a table from the outer query. In our example, the subquery can be considered correlated since it references the d.Id property from the document table which is contained in the outer query. It is also important to point out that implied JOIN operations are not as efficient as explicit JOIN operations since the join condition is not specified immediately resulting in larger table reads. Above we utilized an explicit JOIN operation and below we show an example of an implicit JOIN operation:

• SELECT d.Id, r.alias FROM resources r, document d WHERE r.Id = d.Id

If you want to take it a step further, really crack down on the type of joins being utilized to reduce the size of returned datasets (types of JOIN operations explained here).

Table Partitioning
This practice requires a strong understanding of the application logic, and should be evaluated from both a usability and development standpoint. There are two approaches to table partitioning: read-optimization and write-optimization. Let’s start with read-optimization:
The idea is to simply maintain a smaller dataset of frequently accessed data and another table to hold infrequently accessed data. Imagine that you have an extremely generic content management system where each page contains an alias, description, url, and html body with the following table layout:

CONTENT

The alias and description are simply to give a name and summary of the content and the url is obviously the page location. The HTML body will most likely only be accessed when the page is called directly, whereas the alias, description, and url may be displayed in search results and recent item listings. Our resultant tables would look like this:

CONTENT_FREQUENT

CONTENT_INFREQUENT

For write-optimization we are implementing the same exact practice, just with the understanding that we are separating the frequently updated values of a table from the infrequently updated values.

Data Types & Size Constraints
There are several ways to tighten up your data usage by manipulating size constraints and data types. I will provide a few examples and leave the rest to the imagination. By now you should understand that VARCHARs maintain a variable length byte to keep track of how many characters are contained in the VARCHAR entry. If we are handling data entries that have a known fixed size, such as zipcodes, it is beneficial to use the CHAR data type as opposed to a VARCHAR since we are eliminating the need of the length determining byte. This may seem small at first, but after a thousand entries we are effectively eliminating a kilobyte of additional data. The worst memory hits come in the form of redundant data entries. It is important to implement proper database normalization to reduce redundant entries as well as other undesirable attributes. See my first Schema Busters entry for more information on database normalization.

Conclusion
If you have been following along from the first entry in this series you should now have enough information to crank out an extremely clean and efficient database design. If there are areas that still remain grey, I highly recommend picking up a textbook on database systems such as the Fundamentals of Database Systems by Elmasri & Navanthe. Also be sure to check back for future entries on improving database and application efficiency. From this point on we will be moving into application-level concepts to improve efficiency and promote usability. Any additional related database entries can be expected in the form of an addendum.

The importance of Database Indexing and its effects on efficiency.

“Schema Busters” is a multipart technical overview of Database Design elements that you can implement when designing and accessing your database implementation. In this second section we will discuss the importance of Indexing database columns to speed up data accesses. We will discuss the pros and cons of indexing, and describe the logic behind Indexes.

What is an Index?
Think of database indexes like you would an index in a library book. When you go into the library and need to find a book of a particular genre, you usually head straight to the genre’s section. This is similar to performing Select statements on non-indexed tables. You might be looking at the right shelves but you don’t necessarily know where to start looking. Indexes help to more quickly identify the location of a book, or in the case of databases a record.

How do Indexes work?
Take our library example from above. What would be an efficient and simple solution to help speed up the time it takes to locate a particular book? Sorting! Let’s sort all of the books by their title, and now anybody who knows the title of their book can quickly slim their search down to a significantly smaller number of books. Database indexes work in the same exact way. Indexes keep track of a sorted set of values with an associated row number that allows them to point back to the original record containing the sought index value.

Creating an Index
You can create an index on a table column either at table creation or by using the CREATE INDEX syntax. Listed below are examples of both of these approaches on the same table with the same results:

• CREATE TABLE Settings
  (
  settingId INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
  settingName VARCHAR(128) NOT NULL,
  settingDescription VARCHAR(512) NOT NULL,
  settingGroup VARCHAR(256) NOT NULL,
  settingValue VARCHAR(512) NOT NULL,
  INDEX(settingName),
  INDEX(settingGroup)
  );
• CREATE TABLE Settings
  (
  settingId INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
  settingName VARCHAR(128) NOT NULL,
  settingDescription VARCHAR(512) NOT NULL,
  settingGroup VARCHAR(256) NOT NULL,
  settingValue VARCHAR(512) NOT NULL,
  );
  CREATE INDEX indexSettingName ON Settings (settingName);
  CREATE INDEX indexSettingGroup ON Settings (settingGroup);

Efficiency Comparisons
Indexes manipulate the fact that they are looking through sorted records in order to refine their search scopes to specific regions by doing simple comparisons. While the method that indexes refine their search scopes is dependent upon the DBMS and the type of Index being created, we can still show a generic example of efficiency improvements due to indexing based on the concept of binary searching. Keep in mind that this is a rudimentary example of indexing logic and is simply an estimate of efficiency gains. Again we will refer to our library example when determining efficiency gains. Let’s assume that the number of books contained in this non-indexed library is N, where N is any real whole number greater than 0.

Imagine that you are looking for a particular book in a non-indexed library. Where do you start? Best case scenario is you will pick up the book you want first, however in the worst case scenario you could end up looking at every single book before finding the one you want. This yields a best case of 1 comparison versus a worst case of N comparisons.

Now imagine that you are looking for the same book in an indexed library sorted by book title. We can now logically eliminate half of the books to look through simply by comparing the middle book title with our sought after title. In one row comparison we have halved our search time, and the greatest part is this process can be applied recursively! This yields a best case of 1 comparison versus a worst case of log2(N) comparisons. The logarithmic base of 2 comes from our division into two subsets equivalent in size.

First let’s note that in the best case we gain nothing, however efficiency is better evaluated in the worst case or in an aggregate of the two. In the worst case we considerably reduce the amount of books we will have to look through. If you are familiar with Big-O Notation you will notice this difference immediately. If you’re not familiar with Big-O Notation, try substituting 1,000 for N. Our non-indexed library has a worst case of 1,000 searches whereas our indexed library has a worst case of approximately 10 searches. It takes 1% of the time to find the book we want in the non-indexed library (if we’re considering the worst case scenario)!

Side Note
If you have been using databases for a decent amount of time you have probably already come across indexes but may not be immediately aware of it. Primary Keys and Unique constraints are actually forms of indexing. By default these indexes are clustered, but you can specify otherwise when creating the constraint. This is important to note when deciding how to define primary keys for your tables.

Index Issues To Consider
Indexing is only beneficial to access queries, so before you go and add indexes to all of your tables on every column possible know that indexing can have a negative effect on your database performance. Indexing columns will increase the time it takes to perform INSERT, UPDATE, and DELETE commands since the index will also need to be modified appropriately to reflect changes. Always ask yourself “Will the majority of activity on this table be SELECT statements?” and “Where do I want to see stronger performance?” before adding indexes to a table.

It is also necessary to consider which columns you wish to index. Take our library example again: If we knew the author’s name but not the book title, then we would gain no benefit from an index on book titles. We would need to add an index on the author attribute instead of the book title column. In all reality you would probably benefit from an index on both attributes, but it is hard to understand multiple indexes with our library example since we cannot sort books by author and title separately due to physical limitations of the books. Fortunately there are no physical limitations with database data so it is entirely plausible to have two separate and distinct indexes. Choosing which columns to index is highly dependent upon project and client specifications. If you are having trouble identifying where you need to insert indexes consider using a database analyzer that can track where you are experiencing the most transaction traffic and provide suggestions that may benefit your database design.

Conclusion
Almost every project you come across can benefit from indexing database tables. Learning how to properly create indexes and utilize them to your advantage can further increase their usability, and the best part is they are relatively simple to understand and implement. Indexing is one of the primary means of boosting application speed, especially with a database-heavy application. For more information on indexing consider picking up Fundamentals of Database Systems by Elmasri & Navanthe or another database schema textbook.

It’s no secret we love jQuery here at lifeBLUE. It’s made our life easier and our applications better. One task I find myself frequently doing is finding something nested within the tag or element I’m working with. For example.

<div id="iKnowAboutThis" >
    <div class="one" >One</div>
    <div class="two" >Two</div>
    <div class="iWantThis" >Three</div>
</div>

I know all about the div element with the id of “iKnowAboutThis”. I can get at that with a simple:

var iGotIt = $("#iKnowAboutThis");

I can use the jQuery object to do whatever I want. But what if I need to get at the element with the class “iWantThis” that is nested within “iKnowAboutThis”. If I have more than one on the page then I can’t just do this:

var iGotThis = $(".iWantThis");

If I do the above, I’ll get all of the elements with that class. All I want is the one nested within “iKnowAboutThis”. Fortunately, jQuery has a very powerful tool to help me.

By using the context option within the jQuery selector I am able to get at any nested item I want like this.

var iGotIt = $("#iKnowAboutThis");
var iWantThis = $(".iWantThis", iGotIt);

With that little snippet, my search for elements with the selector I specify stays within the context I set for it.

There you go, simple!

jQuery does produce a buzz. Some people love it, some people… not so much Many more just don’t get it. We at lifeBLUE love it to death, and with good reason. We spend more time creating great interactive applications and less time trying to make those applications work across all browsers. It’s a win-win for our customers and our developers.

However, there are the detractors. While some of them dislike jQuery from a purely philosophical standpoint, most just don’t truly understand it. These misconceptions fall into three categories. Let’s take a look.

“jQuery isn’t JavaScript”
Yep, your right! It’s not JavaScript. That may just be because NOTHING is JavaScript JavaScript does not truly exist. JavaScript is a technology recommendation that nobody really follows. EVERY browser vendor changes how they implement JavaScript every major version change (be it ever so small). In fact, it’s EXACTLY like the “Code” in the “Pirates of the Caribbean” movies; it’s more of a suggestion and can change whenever the browser vendor decides it’s going to change.

So… jQuery is no more or no less JavaScript than anything else written by any other developer anywhere. In fact, one of its stated purposes is to bridge the gap between the various browser’s implementations of JavaScript. jQuery does not require any special technology a browser doesn’t already implement. It does not require any special configuration changes to a server. It’s as “plug and play” as JavaScript gets.

“jQuery is cheating”
Whenthe “rules” of JavaScript really don’t exist you can’t cheat, can you? In fact, to use jQuery, you have to follow standards. jQuery has been around long enough to have a mature feature set and API. It stands worlds above any JavaScript standard in terms of consistency and predictability. If anything, jQuery levels the playing field so that you don’t have to cheat. You can use the same code for every browser, no hacks required.

“jQuery has to much overhead”
Of all the arguments against jQuery, this one has the most validity. jQuery does use memory, bandwidth, and processor power. This point is conceded. However, so does any other piece of JavaScript ever written. The total download size of the jQuery library (in the minimized version) is about the size of a small logo (around 55k), so it does not take much bandwidth. As far as processor power, it does not take very much more or less than any other JavaScript doing the same operation. So while jQuery does take up some resources, it will only really be an issue on really old computers with really slow connections.

In short, jQuery is a great option for most everyday JavaScript tasks. You can produce clean, lightweight, effective code simply. What’s not to like?

For the first time here at the LB, I’ve decided to write a blog directly reflecting my role. Sure we all write about industry related topics, as a team, we all basically perform any and all duties we can to build a website. Whether it’s designing, coding, coming up with a domain name, or talking search engine strategies, we’re all in this together.

Allow me to introduce myself (better late then never, right)… I’m Shauna, our Front End Developer. For the non-nerdy type, that basically means I turn an image into a website, for the somewhat-nerdy, I take the completed design and build the “front end” of what soon becomes a functional website, and for the super-nerdy, I’m responsible for the HTML/CSS side of things.

As with most things, we all have our “style”, “habits” or “the way we think it should be done”. In coding, here at lifeBLUE, you can look at code and immediately know who did it. One of the things that I prefer to do, that can be done probably 20 different ways, is do all navigation in a “list” format. Again, super nerds let me speak your language, <li>’s. It doesn’t matter how simple or complicated a navigation is, whether its live text or images, horizontal or vertical, jpg’s or png’s, whatever the situation may be, I promise you, you can build it in a list. (subliminal message: feel free to prove me wrong, in which I will then show you how it can actually be done).

Why? Several reasons. The OCD in me says do it this way because aesthetically it’s cleaner code (oh, how pretty it looks), but the technical side screams for the search engine aspect as well. Search engines prioritize lists and recognize lists as being a navigational element. So we should take advantage of this and use it properly. It also allows us to associate text with what could essentially be image-based only nav, where you would then lose out on this important feature. It’s also easy for editing, all controlled by the CSS, allowing for simple additions, deletions, and complete makeovers.

So here we go, my time to prove I may know what I’m talking about…

CSS:

.nav {width:500px; height:50px; background:#e00260; font-family:Verdana, Arial, Helvetica, sans-serif;}
.nav ul {margin:0 0 0 18px; padding:0;}
.nav li {margin:0; padding:0; list-style:none; float:left; font-size:18px; line-height:50px; text-transform:uppercase; color:#CCC;}
.nav a {color:#FFF; font-weight:bold; text-decoration:none; padding:0 12px;}
.nav a:hover {background:#c80055; color:#FFF; font-weight:bold; text-decoration:none; padding:14px 12px;}

HTML:

<div class=”nav”>
<ul>
<li><a href=”#”>Home</a>|</li>
<li><a href=”#”>About</a>|</li>
<li><a href=”#”>Portfolio</a>|</li>
<li><a href=”#”>Contact</a></li>
</ul>
</div>

CSS:

.nav2 {width:500px; height:50px; background:#9101b0; font-family:Verdana, Arial, Helvetica, sans-serif;}
.nav2 ul {margin:0; padding:0;}
.nav2 li {margin:0; padding:0; list-style:none; float:left; font-size:15px; line-height:50px; text-transform:uppercase; letter-spacing:-.5px;}
.nav2 a {color:#FFF; font-weight:bold; text-decoration:none; width:125px; height:50px; background:url(nav2_bg.jpg); display:block; text-align:center;}
.nav2 a:hover {color:#FFF; font-weight:bold; text-decoration:none; background:url(nav2_bg_over.jpg);}

HTML:

<div class=”nav2″>
<ul>
<li><a href=”#”>Home</a></li>
<li><a href=”#”>About</a></li>
<li><a href=”#”>Portfolio</a></li>
<li><a href=”#”>Contact</a></li>
</ul>
</div>

CSS:

.nav3 {width:500px; height:50px;}
.nav3 ul {margin:0; padding:0;}
.nav3 li {margin:0; padding:0; list-style:none; float:left;}
.nav3 a {width:125px; height:50px; display:block;}
.nav3 span {display:none;}.nav3 li.home a {background:url(nav3_home.jpg);}
.nav3 li.home a:hover {background:url(nav3_home_over.jpg);}
.nav3 li.about a {background:url(nav3_about.jpg);}
.nav3 li.about a:hover {background:url(nav3_about_over.jpg);}
.nav3 li.portfolio a {background:url(nav3_portfolio.jpg);}
.nav3 li.portfolio a:hover {background:url(nav3_portfolio_over.jpg);}
.nav3 li.contact a {background:url(nav3_contact.jpg);}
.nav3 li.contact a:hover {background:url(nav3_contact_over.jpg);}

HTML:

<div class=”nav3″>
<ul>
<li class=”home”><a href=”#”><span>Home</span></a></li>
<li class=”about”><a href=”#”><span>About</span></a></li>
<li class=”portfolio”><a href=”#”><span>Portfolio</span></a></li>
<li class=”contact”><a href=”#”><span>Contact</span></a></li>
</ul>
</div>

Let’s face it. Form validation is about as much fun as playing tic-tac-toe against yourself. It is a dull task that has to be done but really isn’t that much fun. Mostly it’s just a thousand “if” statements. Of course, the bigger the form the bigger the pain.

jQuery to the rescue.

While there are lots of great jQuery plugins for form validation, you can do it simply without any of them. If form validation is complex, a plugin might be useful, but for things like “contact us” forms or forms with lots of text inputs but no complexity then this method works great.

First let’s do some HTML.

<form action="/the/target/file.php" method="post" id="form1" onsubmit="return checkForm();">
    <label for="field1" class="reqtext">Form Label 1</label>
    <input type="text" name="field1" class="req" />
    <label for="field2" class="reqtext">Form Label 2</label>
    <input type="text" name="field2" class="req" />
</form>

Notice the two CSS classes placed within the tags. These two classes, “reqtext” and “req” are the jQuery identifiers we will use to discover and then check each input field. Also notice that we put in an “onsubmit” element in the form tag. I like to use these instead of the jQuery.submit(). You can work either way. I’m just more comfortable with this format. Here’s the jQuery statements.

function checkForm() {
    // Initialize our error flag
    var error = false;
    // Cycle through the tags with the CSS class "req" in them.
    $('.req').each(function() {
        if($(this).val==()) {
            error = true;
        }
    });
    // If the error flag is set, set the titles for all required fields to a
    // nice shade of red to let them know which fields are required.
    if(error) {
        $('.reqtext').css("color","#922");
        return false; // don't submit the form
    } else {
        return true;
    }
}

Let’s work through the “checkForm()” function. First we set a flag to record if we have errors. Second we iterate through all the form fields with the CSS class “req”. If they don’t have any text in them, it sets the “error” flag. Lastly, after we finish checking things we provide the user with whatever visual feedback we think is required. In this case we set the text color for all the elements with the CSS class “reqtext” to red. You can take the last step as far as you want.

So there you go. A quick and simple validation that can be used for small forms and large forms alike. It allows you to validate what you want and leave the rest alone. Happy validating.

How to identify programmers and cope with their different coding styles.

Everybody has their only personal touch when it comes to pumping out code. Oftentimes the difference is negligible since similar work items are usually delegated to one programmer or department, minimizing the chance that you will ever have to sort through their source since it ‘appears to work’. Having to decipher another person’s code can be time consuming and runs the risk of erroneous implementation of code. Being able to recognize a particular programmer’s style is the first step to successfully utilizing their work for your benefit. Listed below are a number of different programming styles that you are likely to come across in your workplace along with their distinguishing traits.

The Clutter Bug:

More often than not this type of programmer can be identified by looking at their workspace alone. These ‘cluster-coders’ lack organization and are more concerned with results than upholding standards. Clutter Bugs are the product of loosely defined business requirements, poor fundamental programming education (or a personal indifference towards accepted programming methodology), and not enough team experience. The Clutter Bug gets a bad rap, because they often are the most intelligent programmers. Most Clutter Bugs know their code like the back of their hands and given a conflict can resolve it promptly. Other symptoms include inconsistent lunch schedules, late hours, and unkempt hair.

The Dungeon Master:

These programmers assume that others will adopt and follow their programming styles down to which data structures they use. The Dungeon Master is resilient to change and is always ready to defend their work with a lengthy list of reasons why their style is superior to yours. They are quickly irritable when dealing with other persons’ code, and will become quickly lost if too much or too little whitespace is present. Individually they might stand out from the crowd, but when working within a team environment they oftentimes become the nitpicker and inhibit work from getting completed by requiring that all deliverables meet their standards first and not the clients’. Some Dungeon Masters are the product of the Dinosaur mental block (can’t teach an old dog new tricks), but more often than not they are just prideful and have an insurmountable prejudice.

The Spatially Aware:

If there was a beauty pageant for code-writing the Spatially Aware would win every time, however they might fumble when asked how they would use their code to better the project. The primary flaw of the Spatially Aware is that they probably have spent more time organizing their code than writing it. Some of them are tightly bound by the instructions of their first programming teacher while others simply have some form of textual spacing Obsessive Compulsive Disorder. This type of programmer may make it extremely easy for you to find what you need from their code, but they will struggle immensely with your code if you have not mashed your “tab” button to death. They also tend to waste valuable time making code look presentable even though the client will never touch the source.

The Shape Shifter:

Always looking for a new and improved way to perform the same old trick, the Shape Shifter will solve the same problem three different ways in three different places. Their included files list usually has to be placed within a collapsible tag to keep it from taking up half the page. The hardest part about dealing with a Shape Shifter’s code is learning how their code works or learning the foreign resource they decided to pull in. Other programmers struggle with Shape Shifter code, because it requires them to learn alternative ways of implementing a solution that they are already capable of doing with tried and tested logic. Shape Shifters are usually technical bookworms, random bloggers, and tend to jump into a problem headfirst without analyzing the needs of the project first.

The T-1000:

In the brain/processor of the T-1000, coding standards are expendable. Opening up a T-1000’s code is like opening a Windows Media Video file with notepad. Class and variable names look more like serial codes than descriptive titles, lines of code run together, and commenting is, in the programmer’s opinion, unnecessary. These programmers are living machines and should be watched carefully when working on a team project, especially if you have employees with the last name of “Connor”. If you’re delegating an entire project to a T-1000 rest assured that it will function correctly, but do not expect great documentation. T-1000’s can understand anybody else’s code, but others will struggle to understand the simplest statement of a T-1000 program.

While it is impossible to unite all coders under one programming standard, it is very easy to alleviate several issues that may occur between clashing programmer mentalities by implementing and enforcing rudimentary practices. This can be as simple as defining naming standards, having a logic flow associated with work items (aka use cases), or enforcing good commenting. Below are a number of steps that can assist in tightening the nuts and bolts on your development team:

1. Create a predevelopment process where overall project analysis and design is performed. This includes designing database schema, use cases, naming conventions, and business rules.
2. If your team is large, or your projects expansive enough, you may consider developing a business-specific software development cycle where project workflow can be custom-tailored to your business’s needs and methodology.
3. Getting your developers to discuss their ideas openly in Developer Meetings can help establish what kind of standards are necessary for your workforce, and will also promote constructive technical discussion between programmers.
4. Commenting is a simple and easy way to describe what your code does. This is the only reason commenting exists…so use it!
5. Documentation is painful to compile, but it will save your developers time, your end users even more time, and your customer support department 50% on their phone bill.

In order to get the most out of your developers it is important to recognize the differences and utilize the strengths of your team members. Being able to identify what type of programmers you are working with will save you time, money, and minimize the need for oversight. Taking some of these proposed precautionary steps can drastically increase the efficiency of your development team and also increase the conviviality of your workplace.