I've had the opportunity to work with lots of teams on lots of different platforms in lots of different languages and frameworks. This has been great educationally for me, being able to see more than just two or three pictures. One thing that I have noticed regardless of project, platform or language is the idea of "refactor later."

I think that it's redundant to say that there is value in properly written code, but I'll say it anyway. There is value in properly written code. In an interview one time, I was asked the question "What if I [the project manager] asked you to implement a feature in a given time frame, and you could either do it the 'right' way and miss the deadline, or implement a hack to come back to when there was time and deliver it on time." My naivete got the better of me, and I answered the question the way I thought the interviewer wanted it. "Well, I'd write a test case, implement the hack, and then come back, and using the test case to make sure code didn't get broken, do it the right way." I got the job, and one month into it, I regretted it. The entire attitude of implementing the hack to get out the door was what the whole company was founded under. On the tail end of the job, I was blamed for IMPORTANT code being rolled to production commented out, functionality that only appeared to work being pushed to production, and spending too much time developing what was "simple functionality." Yea, if the code wasn't breaking every time I added a new line...

The "refactor later" pattern plagues so many projects for no reason. From my experience, it stems from a desire to design properly, only to have an issue come up that was unforeseen. The solution is throw something together that works, and "refactor later." I would say, though, that the "later" never comes, and the "refactor" never happens. This amounts to bad things like repeated code, inefficient code, and even unused code.

When I first started getting into electronics and gadgets, I learned a valuable lesson: "Buy cheap, buy twice." I would like to create a similar stigma to a similar situation of cutting corners to cut costs in software development. While I'm not good with the clever wording, it would be something to the effect of "every line of corner cutting code exponentially effects your ability to refactor later." By writing "refactor later" code, you're increasing the threshold on when that "later" happens from maybe a few minutes to days and weeks (and maybe months) refactoring code that, having been written cleaner before, would have been more maintainable, and easier to add functionality to later on.

A very good colleague and friend of mine were discussing development today. Many of my geek friends are sysadmins, and, while that entails some programming, the conversations are usually heavily weighted in other matters, so this discussion was very refreshing for me.

My friend has most of his experience in Java, and much of my Java experience has been from school, so I asked him a question that no one has been able to answer for me: "Why is it better to have something implement an interface in java rather than just inherit from a base class?" Much of his response is stuff that I had heard already, e.g. multiple interfaces can be inherited (which I don't care for, because I think there's better solutions than multiple inheritance), allowing inheritance from a abstract class and then implementing an interface. All of that was nice, but then he said something that I knew, but hadn't really let sink in. We write code for other developers, not for the machine. The compiler makes sure that your code is readable by machine. If that's what your problem is, fire your compiler, not the developer.

My friend then went on to talk about the concept of Design by Contract, which he originally introduced to me months ago (and I have since elaborated on the concept in my personal time). It was then that he used a word that I hadn't considered using before: culture. He said developers need to get into the habit of developing a culture of programming.

Having lived outside of my native country, and having experienced many different cultures, I can definitely appreciate different cultures and ideas. A perfect example: On Sunday, I like to watch the Denver Broncos play American football. A friend of mine who lives in London prefers the Manchester United. When I lived in the Carribean, everyone watching cricket, and I mean everyone. I love soccer and cricket more than I like American football, but it's a different culture. We Americans are very business oriented, quick and to-the-point, while many other cultures are far more "people oriented," and enjoy knowing about a person long before they sit down to work with them.

What does culture have to do with programming? Simple. My culture is no better or worse than any other culture, but it's something I'm used to. Is it perfect? No. Is it universal? Nope. Does it work in this situation? Yup. It's the same with programming. Having worked as an independent contractor, I've had to learn to integrate into many different development teams. This means that I learn the culture of the team. One PHP team can be much different than another, with different practices, different methodologies, and different implementation ideas. Sometimes, there are better ideas than others, but when you start a project in one culture, it's sometimes easiest for developers to stay with that culture, even if another would have better results in X area or Y implementation. It makes the code easier to read, because that "culture" has been developed.

What are some of the ideas you have used in past development cultures that you find helpful? Is it a mishmash of various Agile practices? Was it a consensus of the team to develop a "best practices" guide, and published in a document or on a wiki? What works for you, and what doesn't?

Today, I went into the office for a team review of our first stab at the agile development methodology Scrum. We didn't get nearly as much as we planned completed, for multiple reasons. However, during this whole development cycle, I've learned a few things about general development and developed my own practices based on what I've learned, so I thought I'd share with you some of the things I've learned. Many of these ideas are not new, nor are they even new to me, but I mention them mostly because they were reinforced into my mind, which means that it only has to happen a few more times before it clicks, ent?

It's a Buffet, You Can Come Back

One of the biggest problems is that we're undergoing some major changes to our codebase (read: complete re-write of most of the codebase). So when we started, we laid out all of our tasks on the board. It was quite a daunting task. We had a new database model, a new web framework, and the implementation of all existing functionality to port. This was quite the task. However, in our excitement, we did what I end up doing at a buffet on a normal basis: I forget you can come back for more, so I get more than I can eat in the first place. So my task list was humongous, and large task lists are bad for productivity.

The whole point of Scrum is to take small steps to accomplish a larger goal. Understand that you can come back. The stuff you couldn't squeeze into this cycle into another later on. Prioritize. Take the stuff from the buffet that you'd like to warm up with (like a salad, or modifying your framework for your specific needs). Build out from there. Pretty soon, you'll have built something that allows you to add new features in only a few weeks.

Boil the Ocean One Kettle at a Time . . . And Ship The Kettles!

My biggest problem was getting started. Rewriting code is difficult (at least, re-writing this code). Working with a new framework comes with a learning curve. Creating all the base libraries is time consuming and requires a lot research, research that only comes from actually developing the platform. All three of these problems, along with the unfortunate motorcycle accident of another developer, led to a slow start.

My biggest problem is that I wanted to get the libraries and models written right the first time. I think the biggest contributor to that was the plethora of books I've been reading, trying to improve my development methodology. It worked, but I also had to stop reading about it and do it. I think after I realized once again that the library would grow based on its needs. Instead of writing it one way, realizing it was wrong, and writing it another way, lathering, rinsing, and repeating, I just started with what I had, used it in some implementations, and found the problems there. This led me to change the libraries, fix the implementation, and then rinse, lather and repeat. The library code grew at an alarming rate, I found limitations in the framework that I was able to improve (hooray for open source), and created an implementation. It's definitely not the final product, but I know everything I need to know to fine tune it completely.

Keep Your Cycles Like Your Meetings : Short and Sweet

Our development cycle was a month long. That was too long. I spent a lot of time spinning my wheels, getting discouraged because I wasn't getting anywhere, watching the workload not shrink, but feeling like I had all the time in the world. After two weeks of that, I re-evaluated my process, and realized that I was literally trying to boil the ocean. I then sat down and shrunk my workload (see above), and made out a plan to finish only one set of functionality by the end of the cycle. Low and behold, two weeks of time was just enough for me to do what I needed to get done. There were snags, but it also meant that I worked more focused, set smaller goals to accomplish a the end goal, and took each set of goals day by day.

Along with that, we had daily status meetings in the morning. Almost all of our team telecommutes three days out of the week (including myself). The basic idea was that each member of the team accounted for what they did the day before, what they had planned for the day, and whether or not anything was blocking them from continuing (and what the blocker was). These meetings allowed visibility for eachother, and allowed us to coordinate our efforts. Seems that another developer had the same epiphany I had about the same time, and "with [our] powers combined" we provided a pretty decent deliverable (sorry, it wasn't Captain Planet).

As you'll find from my entire site, I'm completely infatuated with all facets of technology, from Atari Punk Consoles to javascript network enumerators to simple tools to make my life easier. I've been blogging since I was 15, but never with the focus on anything as I do now on technology. However, I've been wondering for quite some time why I do what I do, and why others do the same, i.e. blogging about stuff most people know about already.

Many of the blogs I have read in the tech blogosphere are people blogging for the sake of "hearing themselves talk." In fact, I often wonder if peple stumble upon my site and wonder the same about me. Frankly, there's a reason I read blogs, and there's a reason I read blog comments. That reason is because I love to hear differing opinions. However, I write my blog so I can write out the ideas, thoughts, and concepts that I find interesting.

The above image is the result of a study performed in the 1960's by the National Training Laboratories Institute for Applied Behavioral Science. I've read literally hundreds of tech books, about various topics. However, I had never heard of this study, or had even seen this graph. Where has it been all my life?

According to the graph, you have a 10% average retention rate of what you read on this blog. However, as I write this blog, I potentially have a 90% average retention rate of the things I demonstrate here on this blog. This means that I come out ahead with this blog. So I have come to conclusion that bloggers benefit more from their blogs than their readers do. I have yet to find a blog that isn't that way, and I'm sure that other bloggers will agree.

Wanna write better code? Start a blog and write about it...

You'll notice I don't currently have the ability to comment on posts and the like. There's a reason for that. Actually, there are many reasons for that. The biggest reason, however, is spam. There's nothing I hate more than going to a blog and seeing that most, if not all, of the comments are complete spam. I get enough of that in my inbox, I don't want to see it anywhere else. However, I'm also not a huge fan of CAPTCHAs, and don't much have time for the overhead of moderating every comment.

I read Lifehacker every day (thanks to great syndication), and stumbled across an article about phillipino people using their cell phones to make purchases. My ears perked because I work for a company that's trying to do that here in the States, and I decided I'd leave a comment. What I found was a great surprise. They have a "comment audition" form for new users. You fill out your comment, create an account (with an optional email address field), and submit. There's one review process to enable your account and comment, and after that, comments are open to you. Sure, it's another account that I have to keep track of, but it wasn't a painful experience to get it set up. It was easy enough that I was done in just a few keystrokes.

I read a great article by Derek Silvers entitled 7 reasons I switched back to PHP after 2 years on Rails. I've heard just too many "silver bullet" schpiels about X language, or Y framework. Granted, I've got the tools I draw like a gun in the heat of the moment, but just because it works for me, doesn't mean it works for everyone.

I stayed away from Ruby, and particularly Rails, mostly because of the sensationalism. Yes, I did work with it, and I never found anything that gave me an advantage of Python, but it was ultimately the amount of community hatred for anything else that kept me from taking Rails seriously. The ignorance I found in the Rails IRC channels and mailing lists was a major turnoff. There are fanboys and sensationalists in every language, but I found a concentration of them in the Ruby on Rails community.

And this post on Slashdot is why I stopped reading Slashdot a long time ago...

And then my feelings were expressed oh so eloquently in this post by Jamie Flourney. One of the points that really stuck out to me is made is that sometimes writing SQL is a better way to go. Using Django, I was exposed to ORMs for the first time, and while I liked it, I will admit it made me uncomfortable, but it was a new approach. The question though is "Does it really solve the problem at hand?" Django solves most of my problems for my personal site, but it won't fit in some of my other web applications, and that should be understandable. If a tool doesn't work in a particular situation, that doesn't mean the situation is broken.

I just read an article entitled Want to Learn Web Programming? Write A Blog Engine. I'll admit that I learned a lot about web development through working on my own blog engine. I never actually released it live, but it was educational for me. However, I think there are some caveats that need to be considered when making a broad statement. Note: I'm not disagreeing with the author (Abhijit Nadgouda) at all, but there's just a bit more to consider.

First, let me tell you how I got into web development. I've always liked writing code, but school was boring me, and so there wasn't a lot of growth. While doing an aggressive job search for a sysadmin job (which I had real world experience with), I sent my resume to a recruiter who forwarded it on to a company seeking a web developer. I didn't think I had a chance in hell, mostly because I hadn't done anything but dabble in PHP. However, after a second interview, the company took a chance and hired me. I'll admit that it was probably rough rolling for them for at least the first six months while I learned to work as a developer (culture as well as routine).

On the other hand, I have a very good friend (we'll call him Mike) who's been dabbling in PHP (much more than my "dabbling") for quite a while. Mike started writing a comment system for his existing Blogger weblog. It was rather robust, and I am still impressed. He didn't want to learn SQL, so he stores everything in flat text. Having worked with PHP, I know that flat text files are pretty gutsy. However, after looking at his code, it's noticeable that he cut his teeth on an incredibly high level language. He "dabbles" in other languages, but he's pretty skilled at bending PHP to his will. He lacks one very important attribute to his code though: structure.

When I started my first development job, there was software rot. The software itself was organic, which fit its description well, as it felt like working with a large shrub that never had a good gardener. I had the opportunity to assist in the re-write of the entire system. There were implementation problems, there were structure changes, and there were TONS of architecture meetings (even if it was only two developers). This was quite some feat, considering PHP doesn't lend itself to great coding styles.

Now we come to the whole "Write a Blog To Learn Web Programming," there's more to consider. When you start off writing your blog, start bookmarking sites that you find helpful, and if it's a blog, add it to the RSS reader of your choice. Read general programming blogs, read up on other languages. If you write a blog engine in PHP, and then think you know what it takes to do anything in PHP, you'd better think again. It's a starting point, but the world of web development is far from CRUD applications. There's XML processing, RSS syndication, screen scraping, and the like. Creating a blog engine in a vacuum leads to steaming piles of Wordpress.

Make your blog, but then make something else, and realize that you learned very little from making your blog.

3 Oct 2007 - Update: I recently did a review of a few PHP web frameworks that we were investigating at work. My kneejerk reaction was to develop with each one, and see which one provided what I would need for the work application. What did I develop? An identical blog application in each one. So I'll reiterate that the concept of writing a blog application will give you a good overview, but I'm certainly no PHP web application framework expert now.

Jeff Atwood @ Coding Horror posted a few days ago (but only came into my RSS reader today...) about getting his start in programming through writing games on his TI-99. He cites a few other developers who also got their start in games. Jeff continues with a brief history of a possible genealogy for the game Minesweeper, which I'm sure EVERY person who's ever worked at a call center or at a front desk is quite familiar with.

I've been playing video games since my dad brought home an NES when I was five. However, while I attribute the logic and troubleshooting to playing video games (and hooking up the NES when my dad unhooked it so I wouldn't play it), I seem to be among a small minority of developers who didn't get into programming through playing games. I got into writing code through my use of AOL when is was 12.

While I was still too young to apparently conduct myself properly on the internet, I found myself in the AOL internet portal world. While AOL's service is now only relevant to an older generation, I still found many of their services to be of use when I was younger (before there was a Google). I authored my first web page with AOLPress, on AOL's servers, as a tribute to Warcraft II, my favorite game at the time. AOLPress's ability to hop between WYSIWYG and raw HTML allowed me to make a change in the WYSIWYG and view the source, which taught me HTML. While my grandfather might have thought I was 1337, I still had no visitors to my "web site," and I was still really only writing markup, which really isn't programming.

About the same time, I discovered the "underground" AOL presence. I found chat rooms that ran bots to email you mp3s (before it was illegal), software (that I didn't know was illegal), and/or pornography (but I feared my dad more than the government). So while I upgraded myself from midi renditions of "Crocodile Rock" to an mp3 compressed version (that still took >30 min to download at 56k), I also stumbled across a copy of Microsoft Visual Basic 3. I thought it was awesome. I could make little programs that had a button that would pop up a message box that said hi, and it took me only a few minutes. This same underground also used Visual Basic to create helper apps for usage in AOL, like the bot that would email everyone in a chat room the various warez, programs that would scroll macros to the chat room, and even "punters", that would send massive amounts of instant messages to a user containing multiple <h1> </h1> causing (for a still unknown reason to me) the attacker to "punt" the victim from their connection to AOL, causing them to need dial-up again, and usually be confronted by the same offending user "punting" them again.

Now, my first official project in Visual Basic 3 was an antipunter, which introduced me to Win32 programming, and all the HWND sort of stuff (that I've since forgotten). The program was named before it was even developed, and I called it The North Pole Antipunter, cleverly implying that the antipunter gives punters the "cold shoulder." The basic idea was that the system would check for new IMs, and close the IM window immediately. As long as those <h1>'s didn't pile up in a window, you were okay to stay online. So the antipunter could go constantly without you being punted. The problem with the application was that if someone wanted to legitimately IM you, the antipunter would close that window. It didn't check the contents of the IM, only the presence of an IM window. At the point of this discovery, I had EOL'd the program for newer and cooler things.

The drive for me to continue with Visual Basic (and other languages later on) was pure mischief. I wanted to be able to put a program on a friend's computer that would do something funny every hour. I created a piece of software that would shut down my computer at 10 o'clock on weekdays so I wouldn't stay up too late (which became a problem). While I don't condone writing viruses as a way to get into computers, there's a lot to learn in that process that would be invaluable later on in life.

So I guess I did get my start in programming by writing games. The only difference is that my games involved playing with other people.

You've heard of it. All the cool kids are doing it. If you're not doing it, you're living under a rock. C'mon, just try it. The girls will start noticing you if you do it. You'll start meeting all sorts of cool people, and get invited to all the 1337-est parties. No, I'm not talking about cigarettes. I'm talking about fuzzing.

Fuzzing is the process of providing random data (the "fuzz") to the input of a program. Anywhere that input is received into a program, a fuzzer would allow you to test the robustness of your platform. A network fuzzer would be able to construct a random packet of a given type and throw it to an open port. File fuzzers create random files to be opened in a given program. Hopefully, you get the idea. The concept here is not new, but it seems that there has been an increased buzz for fuzzing in the last few years.

This last weekend at Defcon 15, there was a presentation on a network fuzzer called Funk. Fuzzing for me has never been able to draw me to it the way others have clinged to it. Some of that probably has to do with my lack of interest in hardcore security. However, I was drawn to this fuzzer because it was written in Chicken Scheme. Scheme is a great little language from what I've experienced, but I was having a hard time seeing an actual use for the language. So as I sat in the talk, I checked out that code and took a gander. It was a cool idea, and I've already got a little bit of a contribution patch that I'm preparing to submit to the project.

At the BlackHat Briefings in Las Vegas last week, Mozilla released a Javascript fuzzer designed to help browser developers to "fuzz" their browsers to find security vulnerabilities before releasing their products. The media can spin it how they like, but I am glad to see them opening up their tools, and providing documentation on using them. I especially find it useful because Opera, a competing browser, has now used the tool to find at least four bugs in their browser and release a new build. Hooray for communities!

Let's face it, every piece of software has its bugs. However, in the use case that Mozilla is using their fuzzer (and many other companies use their fuzzers), the fuzzing is equal to some great tests. As a web developer by day, I quickly learned that input should ALWAYS be sterilized, no matter how much you "trust" the users of your platform. It's hard, however, for me to find attack vectors in my own software, mostly because I've designed it around one use case, i.e. the one given to me by the "higher-ups." In my mind, I would say "If only I had a tool that would give me some real world use cases," in hopes to cover both stupid users (creating good error reporting) and malicious users (sterilizing the data or failing silently). Creating a good fuzzing tool would fit this bill exactly.

I'm sold on fuzzing now

In the morning, when I come in to work, I usually have a procedure for landing into the day's development. It consists of a variety of things, including reading email, reading the contents of my Google Reader, sometimes a stop at Programming @ Reddit and DZone. After that, I do my Getting Things Done planning for the day, and I attack the day. Depending on what my lunch is like, I may also revisit some of my reading, but sometimes I'm in a groove, and space lunch completely.

Today I found myself reflecting on the last few years, and how far I've come as a developer. A few years ago, I was still trying to grok the first few pages of "Instant Java Server Pages" thinking I needed to understand a web language to create something a bit more dynamic. Now, in less than three hours, I can create an entire CMS software (like the one powering this site) without much of a struggle. I work in a variety of languages, and pride myself on the ability to pick up and use a new language when I find the need to. I was also surprised at how little of these skills I learned in school, and how many of them I learned by actual experience. So I slowly analyzed what it was the brought me here, and began to set some more goals on where I'd like to be in the future. Below are some observations I've made.

Have Passion - I absolutely love writing code. I write code all day at work, and 6 out of 7 days, I come home and write at least a little bit of code. On Saturdays, when my wife is at work, and it's just the puppy and I, I'll spend four or five hours just writing code. When I can't code, I think of ways to improve my existing code, or ideas that would be cool to implement in the future. I can tell the difference between someone who codes because it's their job, and someone who just loves to code. Guess which one is the better developer.

Be A Sponge - I cannot stress this enough. For me, school was a waste of time. Maybe if I went back to get my Master's degree or something, I might find a little encouragement in the college education system. When I landed my first software engineering job, I immediately realized that the people around me could teach me more than any college professor could. I wanted to learn, and working closely with those who would teach me meant that I could soak in everything they said. I also quickly learned to differentiate between opinion and fact, but even the opinions of fellow developers allow me some insight into their coding styles, their development styles, and their work styles. Soak up everything, good or bad, and build yourself with it.

Tweak Your Surroundings - If you're not comfortable in your surroundings, you won't thrive as a developer. I would go as far as to say you won't thrive as anything. For instance, at work, we all use SuSE 10.0, or SuSE 10.2 for development. Now, I have no qualms against SuSE, but I didn't find that it was my kind of Linux distribution. I'm not a KDE user at all, and I found that when I customized my environment, it broke YaST, so I could no longer install packages through the SuSE environment. After having a pretty rough day struggling, I spent a weekend building a Ubuntu Feisty system on a USB hard drive, which I now boot from at work. Sure, I worked the weekend to make sure I wasn't spending my company's time being finicky, but I have seen my development abilities double since I did it. Things like dual monitors, a good window fan, and just the right amount of lighting also attribute to my development ability. Find what works and go with it.

Open Up - I have this theory that if everyone worked at a fast food restaurant at some point in their lives, we'd all be kinder to those who make their living asking about our preference of Super Sizing. I think this also applies to Open Source. I think every developer should at least have one open source project that they work on with regular intervals. Air out your dirty laundry so that everyone can see. Trust me, you're not the best C++ developer in the world (and neither am I), so you're bound to learn something (see above about being a sponge). Have the guts to open up a personal project of yours that may have value in the community. You'll grow from it, you'll become confident in the code you write, and you'll laugh at the code you aren't proud of, instead of fooling yourself into thinking it is the best way.

Share - The open source movement (as well as the Free Software movement) claim that human knowledge is to be shared. We have this powerful network of information called teh Internets, and boy do we use it! The first place I go when I'm trying to figure out a problem is Google. The solution is usually found in a blog post. This is the sole reason I have a blog in the first place. I feel that my knowledge is licensed under the GPL, and I need to contribute back to the community. Maybe as I squeeze out my mental sponge, there will be another sponge waiting to soak up the knowledge.

Read - When you can't code, read about coding. Read blogs. Read books. Read magazines. Read. My wife teases me because I have a stack of technical books at the side of the bed. I don't read them cover to cover usually. I think I've only done one technical book cover to cover, and I did that just to say I did. Rather, I read books until I know enough to do some coding on my own. Somehow the books never make it back to the bookshelf, but every fews nights, I'll pull another one off the bookshelf and bring it to bed. I read a few pages before I go to sleep. Read a book about Design Patterns, then read one that is Anti-Design Pattern. Read a Python book, then read a Ruby book. I've been swapping between Rootkits: Subverting the Windows Kernel and The Linux Kernel Primer: A Top Down Approach for x86 and PowerPC Architectures recently. This allows me to see how the Windows kernel contrasts with the Linux kernel. It has been eye opening to the different design philosophies for me. Read all you can, and then read some more.

Expand - Decide right now that by the end of the year, you'd like to know at least one new programming language. Stretch yourself here. Don't decide that you're gonna learn C++ if you're a C developer. Learn SmallTalk. Learn Java. Learn the Linden Scripting Language from Second Life. I find myself going to Google Video and typing in Tech Talk, browsing for an interesting video, and watching it, or loading it to my iPod to watch later. A coworker of mine, who is a very good developer, was asking about a approach methodology for a problem. At the time, I was the most inexperienced developer in the room, but I suggested something similar to what I had used while working with the Qt GUI framework, which he liked, and implemented. If I hadn't been working with Qt, or the open source software that I was working on, I wouldn't have been in the position to suggest the idea in the first place. If you find coding mundane, you'd better mix it up a bit.

There definitely are those people who have a knack for software development. Others don't. But good developers are indeed made, not born. There are "muscles" that you have to exercise, and stretches you need to do. With the right training though, anyone can become a good developer.