The process of the show is fairly straightforward. First the driver may introduce their car, and the contestants may ask them three questions.  Usually something about estimated horse power, if the car has nitrous, or other types of modifications or parts. The contestants make their guesses, and the driver runs down the track, and the person who is the closest gets $100. Repeat until the end of the show, whoever has the most wins. The video below explains it.

To tie this back into software development, and how this is like estimating a feature request. Usually when some one requests a feature, you as the software developer has to come up with an estimate on how long it will take. The requester or an intermediary will come to you and explain the feature, you will have to ask them questions, these questions will help you figure out the basic details about the request.

You like the contestants you must rely on your knowledge and experience to put up a guess on how long it will take.  It is an educated guess. Maybe there will be a driver or mechanical error which could drastically alter actual time. The same is true implementing any feature, maybe their will be programmer error, or an unforeseen complication with the underlying system. Our best estimates will not usually take this into account.

Some people are better at estimation, but a lot of estimation is experience. Usually the first question or thought you have is: “Have you seen something like this, or at least something with similar components.” The more projects you work on, the more you can observe and learn about what slows down or speeds up a project, and use this as a base for estimates. Most quick estimates we make a calculation of a positive and negative factors on some base which is familiar. This is exactly what the contestants are doing.

Bookmark It

Programming in assembly requires you to think in bits and bytes. You must allocate your own memory. You have to move data into registers and directly perform arithmetic and logical operations on bits and bytes of data, rather than just defining a for each loop and iterating through objects. Using assembly is in effect directly telling the processor which instructions to execute on which data. You learn how to do the heavy lifting rather than having a high level language do it for you.

Assembly programming can help shore up your knowledge of existing languages. One area where assembly is very effective is understanding memory management. Even though memory management is now handled by modern language with garbage collectors. In assembly we have to explicitly define how much memory we need. We may define 64 bytes for an array, rather than just defining a variable for a list and initializing the object without ever knowing how big that list is. Understanding how memory is allocated can help us minimize the overall foot print of all of our applications and be more efficient.

Beyond this experience with assembly allows you to experience how processing happens. How expensive it is to move things to and from memory and processor. How expensive and slow accessing non memory data such as disk or network resources. It gives you a better feel for bottlenecks in applications. This knowledge becomes extremely valuable when optimizing applications, and understanding how and when to make time and space trade offs.

Overall assembly programming showed me the whole picture of programming from typing in code, compiling the code, and finally running an executable.  This solidified many of the concepts I had learned, how algorithms work and why some are orders of magnitude more efficient, and how data structures are allocated and processed.  These higher level concepts directly improved my knowledge of programming in high level languages, and allowed me to make wiser technical decisions because of it.

Bookmark It

Practice Writing

Above all else, the more you practice writing the better you will be. When I left college my writing was not up to par. It did not improve until I started practicing. My writing may not be perfect, but it has shown vast improvement, because I practiced writing.  Many ways exist for you to practicing writing documentation. Here are just a few that I used.

• Start writing in a blog about technical material you interested in.
• Document your own work. You can use a personal wiki. TiddlyWiki is one example.
• Just sit down and write anything. Just write.

Read Other Documentation

Reading documentation is a way to broaden your knowledge of documentation.  The more you read the better writer you will become. Reading other documentation can help you learn a learn from other’s successes and mistakes. Here are some ideas for reading other documentation.

• The O’Reilly Books great example of technical documentation for Programmers and Administrators.
• Documentation of technical tasks for non-technical users.
• Find similar documentation to the technical item you want to document.

Know Your Audience

Before you ever start writing, ask yourself who is my audience? This sets the stage for the tone of the document and how the information should be presented. Here are a set of questions to clarify who your audience is.

• What technical skills do my users posses?
• What terms will make your users comfortable or feel uneasy?
• What reading level are your users?
• Are they comfortable with technical writing?
• Do they understand the non-technical aspects of the task?

Be Consistent

Keep your documentation consistent. Consistency reduces the barriers to following a complex idea. It increases readers comprehension of the document. Here are some tips on consistency.

• Use consistent jargon ex: If you call a link by the term hyperlink, do not use the term link later.
• If you are adding to a document try to follow the existing writing style.
• Use a consistent writing style.
• Use consistent and proper spelling.
• Use the same font styles consistently.

Write Clearly

There are many ways we can clarify documentation. Technical language is sometimes a necessity, but that does not have to effect the clarity of our writing. Here are some tips for making your documentation slightly more clear.

• Define jargon and acronyms when they are introduced.
• Do not skip steps when documenting tasks.
• Highlight problem areas, potential pitfalls, and common mistakes.
• Provide concrete examples.
• Use the simplest words that work.
• Avoid complex and run on sentences.
• Use paragraphs to isolate larger concepts.

Efficient For the Reader

The only thing worse than incomplete documentation, is inefficient documentation. Writing an efficient document goes hand and hand with clear documentation. Do not make your users search through loads of documentation. Make the important points stick out.

• Good headlines and Sub-Headlines will allow your users to effectively scan content.
• Good section grouping will allow users to find similar concepts quickly.
• A search function for online documentation is extremely effective. I recommend using a Wiki.

Conclusion

These tips will not make you a better writer over night, but they can help you become more cognizant about what you are writing. Below are a list of tips and resources to help with writing documentation.

• The Elements of Style
• Introduction to Technical Writing/Documentation
• OWL (Online Writing Lab at Purdue)
• Software Documentation via Wikipedia
• Key for Effective Documentation

Bookmark It

The programming languages you dine on is based in the same principals as your culinary choices. These decisions are based in your culture. Many factors which contribute to your technical culture: where you learn, where you work, and where you play. Reading these cultural factors can help us understand why a person or an organization picks the languages they do.

Some of us choose us prefer a buffet of languages, and like to sample a little bit of every language. Some choose to stick with a couple core choices and savor every little piece of a language. On the other hand you have your diet specific programmers, such as you free software-gens, and the script-arians.

Sometimes our jobs require us to use a specific language, or the technology requires it. Utility is largest factor in choosing languages. Secondly what you learned and perfected you programming is a close second to choosing which language to use. Tertiary factors are general community factors, such as what are the current trends, what would you like to learn. All of these factors relate to how we choose food, what’s available to us to buy, what our families have eaten, and what we are recommended.

On a side note. The programming languages you choose to dine are signals to other programmers. Just as you culinary choices are signals to other people. These signs, and signals many times are more rooted in stereo type. So many programmers may learn a specific language to affect their appearance to others, just as some people make dining choices to impress other people.

Finally as I discussed earlier the biggest factor in choosing a programming language is the utility, and what we cut our teeth on. Just as many times primary food choices are based on utility, and then what we learned from our families. Understanding these factors can help us grow as programmer, and understand what programming languages we consume.

Bookmark It

The web view of the data has been upgraded to provide more information. The Des Moines Twitter Trends website now provides a clearer view of the data collected. It provides current trends for the past few hours, the past day, and the past week. All of the terms are now links to Twitter Searches.

I added some new information, such as recent links, and current view of the latest Twitter user’s avatars in a grid.

I also created my own theme, and display instead of using a third party Wordpress Theme.

P.S.
Here was the write up for the first version: http://www.dotcodedump.com/2009/07/finding-local-twitter-trends.html

Bookmark It

This primer is broken up into major sections below.

Moving Files

If you are like me your web server isn’t the same machine as your development PC at least I hope not! You will need a way to get files to your web servers.

Push: Push deployments are when files are transferred from the client to the server. An example of this would FTP, or many other file transfer protocol. This involves opening up a client, and manually or automatically transferring the files from your PC to another computer. This could also involve transferring them using a network file system. FTP clients are included with most major operating systems.

Pull: Triggering the server to download files from another location. An example of this would be using a third party program to download the files from web or ftp directory. WGet, SVN, or another similar program could be used.

WGet: Gnu WGet is free software for retrieving files over HTTP

FileZilla: Open source FTP client and server.

Source (Revision) Control

Source control is critical for being able to control releases, and code. Source control allows you to version your applications, and download a particular version from your source control repository. There are many flavors of source control. Personally I prefer Subversion (SVN). For information on source control.

SVN: Open source, source control client and server.

CVS: Open Source, been around since the 80’s, Concurrent Versioning System

Mercurial: Open Source, Distributed Version Control in Python.

GIT: Open Source, Distributed Version Control

Bazaar: Open Source, Distributed Version Control

Visual Source Safe: Microsoft’s Legacy Version Control

Team Foundation Server: Microsoft’s Prefered Version Control, as well as project tracking

Automation

When I first started building websites. All my deployments were done manually over FTP, and it sucked! Then I started using a better FTP client, and guess what it still sucked! I dreaded deploying, it was error prone, and I looked like an idiot because I forgot a file here or there. It all changed when I started automating my deployments, and I haven’t looked back since.

Depending on what language, or platform you are developing on or for. It is very likely there is an automation application for you system. There is a large class of open source build automation applications based in some way off ANT for Java, which is java version of MAKE.

ANT and it’s derivatives are build scripts which are programmed using XML. Using the ANT XML files you can control file copying, running builds, unit tests, and a number of other deployment and build related tasks. Most of these applications support building custom tasks in their native language, so if it doesn’t support what you need it is very easy to build on top of these platforms.

Make: GNU Build Tool, best suited for compiling applications, custom file configuration.

Ant: Java Build Tool, best suited for building and deploying Java applications.

NAnt: .NET port of Ant, best suited for building and deploying .NET applications.

Phing: PHing Is Not GNU make, best suited for deploying PHP applications.

Maven: Similar to Ant, but different application, it is network ready, and uses a system know as the Project Object Model.

Rake: Similar to Make for Ruby, and the config files use a Ruby syntax.

Other Techniques and Tools

Divide and Conqueror

Divide applications deployments up into different sections, so it is very easy to pin point major errors. One example of this is dividing a compiled web applications into binary, and non binary changes, and then deploy one after the other.

Differential

Create a deployment of only the files that have changed since the last release. An example would be using source control to download files that have changed, and only deploying those. The advantages are it will reduce time during deployment. It may also have the issue of missing files, or other items.

Putting it all together

These are just some of the building blocks for deployment strategies. Building a consistent deployment structure will depend on the number of production, and QA environments that host an application. Sometimes you may not even have access to the production servers. These techniques, and tools are very flexible to support even the most rigorous of deployment structures.

The deployment process should never be a source of stress, and deployment processes should never be the source of errors. Using a consistent, and stable deployment process will reduce both stress and errors.

Bookmark It

the degree to which a set of inherent characteristics fulfills requirements — ISO 9000 : 2000

The definition is interesting, because it makes no statements about composition or any other property. The only statement it makes is about the fulfillment of requirements.

Software exists because it fulfills a need. These needs are translated into requirements. Secondly software is expected to have certain qualities by it’s users. These are requirements which are many times unwritten. If software does not fulfill most or all the requirements it will be interpreted as poor quality.

Here are some examples of unwritten requirements:

Bugs should be kept to a minimum.
Software should perform well.
Software should be very usable.

Unwritten requirements are not easy to fulfill, and they are ambiguous and subjective. Clearly defining these requirements and expectations. This process is integral to developing software that fulfills users needs and expectations.

Misunderstanding quality is dangerous, and leads to false beliefs. These beliefs cause developers to ignore parts of the software development picture. The only way to consistently build quality software is to define not only the functional requirements, but also the unwritten requirements and expectations.

Bookmark It

There are thousands of blogs on software development. Many of these blogs demonstrate, promote, or even proselytize tools or methodologies. The large amount of information provides developers with a large choice of tools and ideas. Searching for proper ideas and tools is very time consuming.

Software developers put knowledge in high regard. Learning is even more valuable. A good software developer should find a balance, between learning and doing. Programming is not philosophy. Making and creating is far more valuable to good programmers. Good is what works, and works well, not what is academically perfect.

Finding tools and even using tools can become a distraction. Learning when your tools are getting in the way is skill, which is underdeveloped, in many programmers. A perfect example is how programmers can get into holy flame wars over a TEXT EDITOR! This is just one example of where the meta-product, becomes more important than the product, but there are many others.

Ironically I am advocating learning how to ignore programming noise, in a blog.

The Lintner Code Complexity Analysis Test: Next time you start incorporating, tools, methodologies, and other ideas into your code base. Ask yourself could an average developer jump in and get the basic flow, and meaning of the code? If no, you may want to rethink your approach.

Personally I advocate simplicity, and minimalism when it makes sense, and some level of complexity is necessary. Tools create complexity. Tools require knowledge to operate, and they will change how your process works. When choosing tools, you must be aware of how they will effect your software development ecosystem over time.

Technologies, tools, ideas, or just plain noise can get in the way of creating, and making. Many times a small project or tasks can be finished the without tools, in the time it would take to set up, and use complex tool. There are many examples of high quality software that was created without code analysis tools, unit tests, and even a structured development methodologies. Next time you start working on a new project, you may want too evaluate your tools too see if they are truly valuable or just wasteful.

Bookmark It

When making changes to a section of code, causes other bugs, sometimes recurring, to pop up. I.E. You fix one bug, and three other bugs pop up after you release.

Have you ever worked on code where troubleshooting bugs was like playing a game whack a mole. I have worked on a few applications that seem to have taken this idea to heart.

If you encounter an application that not very stable, many time your options for dealing with it are limited. You just have to work within the constraints of the system. Previously I have mentioned, defensive development as a technique to cope with difficult system. This is an example of controlling what you can, the new code, and fixes you introduce into the system.

When dealing with difficult systems your best weapon is going to be communication. Make everything as clear as possible. Make your new code readable, understandable, and most importantly comment what you changed, and why you needed to change it. Keep documentation on the system. Document critical, and time consuming tasks. If a process took you a week to update, document it, and it will take the next guy half as long.

The most important technique for dealing with difficult systems is asking questions, and making sure you understand what people are asking. Many times “whack a mole” conditions are caused by mis-communication, and lack of knowledge.

Maintaining difficult systems is a reality for many developers. This is as important, or more important of a development skill as creating new applications. Many time maintenance programming is far more difficult than new development, because you have to work outside of your code “comfort zone”.

Bookmark It

Recursion

If you are using recursion there may be a better way, or I like to say just because it fits into recursive paradigm, it doesn’t mean it HAS to. There are many times I have found myself ending up doing something recursively, and regretting. My word of warning: “It starts with a couple of recursive functions, and then you wake up 3 days later in the middle of New Mexico in playing Russian roulette with Bill Richardson. Recursion has it’s uses, but with it you probably are going to incur a performance cost that may not be worth it.

Nesting Logic

Any time you start nesting logic beyond 1 or 2 levels this should be a warning sign that something could be a miss. This is where debugging is generally going to start getting difficult. If you are having difficulty coding a section, and it involves nesting of logic this a point where you need to step back and get a second opinion on how to do it. I am by no means saying don’t do it, but watch

Really Long Functions

Writing really long functions is generally a sign of two things, either there is a lot of logic to parse through, or you may be doing something poorly. This may also be an indicator that something else outside of your current scope is amiss. This is generally a point to ask questions, and thoughts on how to program a specific section.

Maze Like Program Flow

If you are constantly searching for functions, and logic, and your program looks like a maze this is probably a point where you should take a step back. This means that either there is some really sloppy code, or there is very high level of systematic complexity. If the complexity does not match the task you are trying to achieve this may a point to step back and take a look at the big picture, and possibly get a different perspective on the situation.

There are many other sets of guidelines, many other people have created. This a small list of warning or “yield” signs that I use regularly. This reflects my general bias for trying to make things as simple as possible, and reducing complexity where ever possible.

Bookmark It