Messy Source Code Repositories

It goes without saying, a messy work-space impacts the ability to be organized and perform well. Everyone has messes, but in a common space organizing and maintaining that cleanliness is essential.

When and Why?

This process should be started immediately in any organization because it will save time and money increasing the pace of development. Rarely in a company is there an opportunity for a software re-write. Technical debt is often put off. The time to make the corrections is every day and then continuously (aka continuous improvement). New processes are typically put into place to manage the extensive mess. These processes potentially only add a layer on top of the existing mess and therefore are complex and generally lack patterns. This must be corrected at the foundation.

Figure 1. A hard copy mess with many similarities to unkept repositories.

Typical Findings

In a comprehensive inventory of messy source code repositories common findings include:

File System

• Extensive irregular source code filing
• More than a few empty or junk (new and unchanged) source code projects, solutions, and directories
• Committed bin and obj directories and files
• Intermingled mixed platform and language source code
• Mixed documentation and source code
• Inconsistent and duplicate storage of 3rd party code and binaries

Source Code

*Restricted to .NET high-level organizational patterns only.

• Namespaces not consistent with location
• Namespaces missing
• Class names not consistent with file name
• Multiple classes in the same file
• Source code files missing from projects
• Inconsistent assembly and project reference patterns
• Ad hock solution creation and composition
• Assembly name/project name mismatch

Starting Recommendation

This is just a start. A starting place must be carved out before the next layer of organization, standardization and patterns can be addressed. These recommendations target only high-level organizational patterns and standards.

Step 1

1. Define, implement and enforce a pattern for source code storage
2. Separate source code based on platform and language (non .Net vs. others)
3. Separate documentation and diagrams
4. Remove any compiled code and add ignore statements to source control for those files and directories
5. Collapse, consolidate and organize 3rd party code and binaries
6. Remove all unused projects, solutions, files, and folders

Step 2

1. Define, implement and enforce a solution (.sln) pattern
2. Install and enforce the usage of JetBrains ReSharper for all .NETdevelopers
3. Fix project properties to match assembly name and namespace
4. Fix namespaces to match location
5. Fix class names that do not match the file name
6. Define and standardize assembly reference policies
7. Clean and standardize all AssemblyInfo.cs code files

Next Steps

After completion of the first 2 steps attention can turn to the code itself. In the next steps it’s important to standardize using patterns. This includes class and project structure, reduction in code duplication, collapsing of projects, namespace cleaning and standardization, removal of legacy or unused code blocks, removal of unused references, standardization of comments, etc. These steps are necessary steps to get to a cleaner working base. A clean working base will accelerate the integration of new code, designs, patterns, bug fixes, unit testing, and ramp-up time for new engineers.

Encountered a fun error: Failed to start up socket within 45000

Encountered a fun error: Failed to start up socket within 45000.

Firefox had updated itself to version 17. The Selenium version is 2.21.0.0 for the following DLLs:

• Selenium.WebDriverBackedSelenium.dll
• ThoughtWorks.Selenium.Core.dll
• WebDriver.dll
• WebDriver.Support.dll

The solution is as follows:

1. Uninstall updated version of Firefox
2. Download and install Version 14 of Firefox. (Other versions may also work, but this worked for me)
3. Launch Firefox and in options make the following changes:

In Response to TRUSTe: Mobile Tracking: How it works and why it’s different

In response to TRUSTe: Mobile Tracking: How it works and why it’s different.  The article is a decent summary of the current state of mobile advertising. There are two things that I think are not well addressed in the article or in some ways misguided. First, is the concept of fingerprinting on a mobile device. Those of us involved deeply in this area understand there isn't additional entropy in a mobile print that allows us to differentiate between 2 devices with the exact same OS. In other words, a fingerprint in mobile (beyond cookies and local storage) is at best IP/UA degrading from there significantly because IP is not reliable in most cases often switching intra-session while on mobile networks and not WiFi. The second misconception (or lack of clarity) is regarding privacy and tracking. DNT does not mean to all market players “do not track” and therefore not monitor behavior or collect data. For example, Yahoo recently announced it would purposefully ignore DNT in IE10. Many companies are interpreting it as they please such as, don’t target but collect data as needed, or, do everything as normal and forward along the DNT value to let the down-stream guy handle it or interpret it as he wants. Enabling a “persistent identifier” as claimed at the end of the article as a way of providing “better privacy” is not true. Enabling a “persistent identifier” enables better tracking, less privacy, but for the companies who choose to respect DNT, it is true that it will help with severing non-targeted ads.

Take What You Can Get - From Form Fills

Many times I've started to fill something out online and decided, ugh, not now, or, there is way too many questions here forget it.  Now, let's just say you decide to close your pof account because really there isn't anyone attractive anyway and up pops a survey so you can tell them what you really think.  Half way through this scroller of a survey you decide, over it, just wanted to let them know it sucked and being the good citizen that you are you scroll to the bottom and click submit. What next? An error? Seriously? The error is asking you to fill out the missing questions.  HA! Okay, that will never happen.  What's the lesson here? Take what you can get, from form fills.

As a web designer, put the submit button at the bottom of the page as normal giving the persistant user their reward.  Asynchronously collect the data after each question is answered by the user. Send it to the server and cache it in the session, stuff it in a database, just get the data somewhere so it can be analyzed.  If 20% of the users fill out a third of the questions, 40% fill out half, and the other 40% complete it, then you get 26 point lift simply by changing how you process the data.  Put the most important question first and you're probably looking at a 99% answer rate for that question for anyone that decides to even touch the survey.  This is a no-brainer, and everyone should take what they can get from form fills.

The Art of Database Selection - Part 1

Selecting a database for the job is more of an art than a science.  That is, aside from the obvious misuse of a database for a particular job the selection may not have everything to do with the technology or perceived cost savings in licenses etc.   Take for example a companies decision to switch databases because of impending or increased license costs.  The transition to a new database is typically well planned and the tradeoffs of development changes required to support it are meticulously studied and documented.  What happens when something goes wrong?  Say the performance isn't at the level that was expected.  What if it's not even close?  Teams and company dollars can get swept into managing unforeseen transitional costs which can include support contracts, hardware changes, engineering investigation, testing, and additional changes all of which delay primary goals of the company. Overall, the cost may far outweigh that of staying on the original database solution and absorbing the increased cost of doing business-as-usual.  So when should a team make that leap?  This is part of the art of database selection.  The switch must yield (at minimum) significant benefits or provide a solution that is not available otherwise.

• Solve a computational problem unable to be solved in a reasonable amount of time by the former database.  Caution here, mere performance increases can be challenging to achieve and should be approached with great reserve.
• Provide a radical reduction in costs where the prerequisite should be existing team expertise and experience with 2 or more engineers on the new database including hardware knowledge and DBA skills: ideal hardware configuration for the job, replication, backup strategies, tuning, indexes, etc.
• A change in use-case of the data such as archiving large datasets into an alternative cheaper solution.  In this case non-production critical data is the best candidate.

Databases are an art and sometimes it is best to stick with what you know and other times it's worth the risk.  Just be sure if you are going to take the leap it's going to be worth the possible challenges.  Sounds like life.