Dot Mac

1. Do you use source control? What kind?  What are the requirements/checks to check in code (assignment to work items, unit tests, peer review, etc)?
2. Do you use a bug database to track all issues? How do you track progress and manage change?
3. Do you use the best tools money can buy? For example: MSDN/Apple Dev accounts, dual monitors, and powerful workstations.
4. Do you have a dedicated QA team? Are they involved in the requirement/release management process?
5. Do you fix bugs and write new code at the same time? How do you balance the two?
6. Do programmers have quiet working conditions and team meeting rooms?  Describe them.
7. Do you solicit feedback from end users or customers during the development process?  How is it used?
8. Do you do a daily build? Do your builds include automated unit tests?
9. Do you have a requirements management system? Is it integrated with your source control?
10. Do you create specification/requirements documents? Do you do it before, during, or after writing code?

My post on the nature of programming seems to have struck a nerve. Many commenters pondered what makes a developer great. “Ka” thought that:

“You [are] not born [a] good or great programmer, you become one with time and study and hard work. At the beginning, everybody is a bad programmer.”

I disagree. Developers are not born “great,” but greatness does not automatically come with experience. Conversely, lack of experience does not make a developer “bad.” The difference between a great developer and a bad developer is not in their domain knowledge, but their methodology. The distinguishing mark of a great developer is that he codes consciously. Put another way, a good developer always knows why he is doing something. From the perspective of personal ethics, this requires intellectual courage and integrity.

Let me give an illustration of what I mean from personal experience:

When I got into Objective-C development, I was a “bad” developer. Most of my experience is with .Net code. Jumping into the iPhone dev world was intimidating. As as a result, I lacked the courage to learn the architecture. I tried to manipulate blocks of code found on the web without understanding what they were doing. I would copy and paste blocks of code and just change variable names. When things didn’t work, I would look for another block of code to substitute for the failing one, or enter “debugging hell” – running code over and over, making random changes and seeing if they worked. This is the hallmark of a bad developer – imitating without understanding. I kept this up for over a year. It’s not that I didn’t try to learn the language. I got several books and watched iTunes U classes. But the way I used the learning materials was to memorize blocks of code and look for places to stuff them into my code. I wasn’t actually learning the platform, just collecting samples. Some developers spend their entire careers this way. They carry collections of old code everywhere they go, and just grab chunks to insert into new programs. They may never select File => New File or File => New Project in their whole career.

After writing a lot of bad, buggy code, I drifted back to the comfort of .Net. Recently however, I decided to change my attitude. I started by downloading some iPhone code samples and open-source applications. I started in main.m and went through each line of code. If I didn’t understand exactly why a certain symbol was used or what it did, I looked it up. I spent a lot of time on Cocoa Dev Central, Developer.Apple.com, and Stack Overflow looking up things like the reasons why you would assign, retain, or copy a property, or when exactly you need to release an object (for alloc, new, copy or retain) or what you can do with respondsToSelector. There’s really not that much complexity to programming languages – but if you don’t take the time to learn how things work, they will always seem difficult and mysterious. If I had just looked this stuff up to begin with, I would have been far more productive. But, I was intimidated by the environment and tried to shortcut the learning process by imitating without understanding.

Understanding anything complex requires the courage and integrity to engage in difficult, exhausting mental effort. It’s tempting to cheat yourself. It’s easier spend more time in endless copying and debugging that take the effort to understand and create. In the short run, it saves time. But in the long run, developers who understand their craft are magnitudes more productive than the monkey see-monkey do coders. This is the difference between the unprincipled kind of laziness that trades understanding for time and the principled kind of laziness which saves time by understanding.

There’s no happy ending to my story — yet. The proof of a developer is in his work, not his book smarts, and I have yet to produce something to brag about.

For more on the traits of great developers, read these posts by Dave Child and micahel.

My experience as a programmer  has taught me a few things about writing software. Here are some things that people might find surprising about writing code:

• A programmer spends about 10-20% of his time writing code, and most programmers write about 10-12 lines of code per day that goes into the final product, regardless of their skill level. Good programmers spend much of the other 90% thinking, researching, and experimenting to find the best design. Bad programmers spend much of that 90% debugging code by randomly making changes and seeing if they work.
  “A great lathe operator commands several times the wage of an average lathe operator, but a great writer of software code is worth 10,000 times the price of an average software writer.” –Bill Gates
• A good programmer is ten times more productive than an average programmer. A great programmer is 20-100 times more productive than the average. This is not an exaggeration – studies since the 1960′s have consistently shown this. A bad programmer is not just unproductive – he will not only not get any work done, but create a lot of work and headaches for others to fix.
• Great programmers spend little of their time writing code – at least code that ends up in the final product. Programmers who spend much of their time writing code are too lazy, too ignorant, or too arrogant to find existing solutions to old problems. Great programmers are masters at recognizing and reusing common patterns. Good programmers are not afraid to refactor (rewrite) their code constantly to reach the ideal design. Bad programmers write code which lacks conceptual integrity, non-redundancy, hierarchy, and patterns, and so is very difficult to refactor. It’s easier to throw away bad code and start over than to change it.
• Software obeys the laws of entropy, like everything else. Continuous change leads to software rot, which erodes the conceptual integrity of the original design. Software rot is unavoidable, but programmers who fail to take conceptual integrity into consideration create software that rots so so fast that it becomes worthless before it is even completed. Entropic failure of conceptual integrity is probably the most common reason for software project failure. (The second most common reason is delivering something other than what the customer wanted.) Software rot slows down progress exponentially, so many projects face exploding timelines and budgets before they are killed.
• A 2004 study found that most software projects (51%) will fail in a critical aspect, and 15% will fail totally. This is an improvement since 1994, when 31% failed.
• Although most software is made by teams, it is not a democratic activity. Usually, just one person is responsible for the design, and the rest of the team fills in the details.
• Programming is hard work. It’s an intense mental activity. Good programmers think about their work 24/7. They write their most important code in the shower and in their dreams. Because the most important work is done away from a keyboard, software projects cannot be accelerated by spending more time in the office or adding more people to a project.

One thing I don’t like about the default Xcode layout is that all the views – code, debug, console, find, etc open in new windows by default.

If you’d rather not manage a bunch of Xcode windows all the time,  Xcode has a “hidden” All-One-One view which shows all your views in a single window and ads a page toggle which conveniently switched between code and debugging toolbars.  You can access under Preferences – General – Layout.  This took me a long time to figure out because the Layout dropdown is disabled when a project is open.  Maybe it’s my Visual Studio background, but I like the integrated view much better.

Here’s an interesting collection of online Objective C/Cocoa tutorials. Can anyone suggest other online resources? I don’t have a good record of reading dead-tree instructional materials :-/

Update: here is a free ebook on OS X development.  I just pre-ordered this (the first edition has great reviews)
Programming in Objective-C 2.0 (2nd Edition) (Developer’s Library)

MonoMate from Julius Eckert on Vimeo.
More.

I haven’t tried MonoMate yet, but I’ve been playing with Monobjc (used by MonoMate), which allows me to write and compile code in Visual Studio 2008, and then build native apps in OSX.

The framework used to tag pages on Mises.org is a tagging library I developed to tag any kind of content on Mises.org.  The tag library references GUID‘s assigned to all objects in the Mises.org databases.
It tracks users by username or IP address as well as the date that each tag was added.  It includes spam/bad word filtering and has some simple tag rewriting to automatically correct misspelled words and incomplete names.  For a simple tag example, see business cycle.

Update: Mises Tagging is now an open source project!  See the project page for details.

Architecture overview:

Database layer:

The database schema gives a good indication of the
data-access layer:

Stored procedures:

UI Layer:

The interface is organized into self-contained user
controls.

• TagCloud.ascx – a tag cloud for the given document
  Example: http://mises.org/resources/3250  (Sroll down)
  
• EditTags.ascx – an editable list of tagged
  documents and a user-specific tag cloud.
  Example: http://mises.org/mymises/
  (You’ll have to register at Mises.com tag some documents first.)
• TaggingStats.ascx – global tagging statistics
  Example: http://mises.org/clouds.aspx#stats

Management:

• DocumentTags.ascx – an editable list of tags for a particular
  document
• Tags.aspx: delete tags, delete all tags by a particular user
  and search/replace tags

The MisesBot:

You might have noticed that 99% of all tags are entered by
the MisesBot.  The bot is an application
that uses the meta tags collected by the MetaParser (detailed in a future post)
as well as other available metadata to add tags to document.

Thanks to:

• Cloud Control for ASP.Net – displays a list of hyperlinks in
  varying styles depending on a weight.
• Toxi – the inspiration for the tag schema
• Freetag, an Open Source Tagging / Folksonomy module for
  PHP/MySQL applications – the inspiration for the business logic layer
• Community Server -  Inspired the tag browser interface and provided the banned words list.

To do:

• Did you notice the TagAuthority field in the tag
  schema?  A future version of the MisesBot
  will automatically determine the “authoritative” document for each tag.
• Automatically mark up content.  If we know the authoritative document for a
  tag, we can automatically link to it when that tag appears in the document text.
• Improving the “related tags” algorithm.  I could use some help with this:

Here is the query to get related tags.  The problem is that it currently ranks tags according to their total popularity, not their “related-ness.”

CREATE
PROCEDURE [dbo].[TagGetRelatedTags]
        @Tag VARCHAR(70)
AS
BEGIN
        DECLARE
                @TagId int
                SET @TagId =
                        (SELECT TagId FROM Tag WHERE Tag = @Tag)
                        SELECT  TOP 30 Tag.Tag,
                                COUNT(TagMap.TagId) AS 'Count'
                        FROM    TagMap
                        INNER JOIN Tag
                        ON      TagMap.TagId    = Tag.TagId
                        WHERE   [TagMap].TagId <> @TagId
                            AND (TagMap.TagId  IN
                                (SELECT DISTINCT TagId
                                FROM    TagMap
                                WHERE (ObjectId IN
                                        (SELECT ObjectId FROM TagMap WHERE (TagId = @TagId)))
                                )
                                )
                        GROUP BY TagMap.TagId,
                                Tag.Tag
                        ORDER BY 'Count' DESC
                END