To be honest I have no clue whether this guy actually knows what he’s talking about but I think it makes sense from where I sit…

“As a cryptography and computer security expert, I have never understood the current fuss about the open source software movement. In the cryptography world, we consider open source necessary for good security; we have for decades. Public security is always more secure than proprietary security. It’s true for cryptographic algorithms, security protocols, and security source code. For us, open source isn’t just a business model; it’s smart engineering practice.”

An interesting rant on object oriented programming in java, bordering on an attach actually. It was a good read, however, I think the story/metaphor went a bit far as I found myself forgetting what we were talking about as I went through it. Some quotes I liked:

• advocating Object-Oriented Programming is like advocating Pants-Oriented Clothing

• I’ve really come around to what Perl folks were telling me 8 or 9 years ago: “Dude, not everything is an object.”

If you read the article, make sure to read through some of the comments, ignoring the pat-on-the-back ‘great post’ ones of course.

Nice quick read sent over by Bobby, Why Is Agile Development Hard?

Don’t let the title of this fool you. While some people may view it that way, this is not an article about why agile processes suck. This is a great little endorsement article about why you want agile if you’re a business owner. To do that, however, you need a team that can actually be successful in an agile process. You’ll only find failure if you take an existing team working in a traditional process and shuffle them over to agile. It won’t work.

Agile is much more difficult. Ultimately it’s about the people. Agile requires intelligent people who are intrinsically motivated and self-managing. You need technical people who are willing to act like business owners. Traditional processes can be simpler and requires less thought, well I think the author summed it up…

“YOU HAVE TO USE YOUR BRAIN!”

His other points:

• Don’t Mistake Activity for Progress
• Show Me Working Features
• Learn to Say “No”
• You Must Lay the Proper Groundwork to Be Agile
• Agile Is a State of Mind!

“In agile development, you (and everyone else) are charged with the rather difficult responsibility of always challenging yourself to ensure you are doing the smartest thing possible that will bring about the best solution for the current project (and within its context).”

While we are far from being agile bigots, we certainly are an agile software company, based on these tenets. We value working deliverable software over activity.

This places a big burden at the front of our funnel during our hiring process. We have to ensure we only bring in people that want to use their brain today and three years from now in the middle of a long project.

If you work in a traditional software process and find yourself pissed off because the process prevents you from doing what you know is right for the business, well email me your resume because we’ve all been there and we’re looking for you.

I was recently asked about Ruby On Rails(ROR) versus .net or java. Specifically, a CEO of a startup is planning to use ROR, in what situation would we use ROR? First off, I have essentially no experience actually developing in ROR so I should really keep my yap shut. Having said that, this is all best guess, big grain of salt stuff. Some of my response is below:

Here’s some specifics to go with that….

ROR is impressive at first look, big ‘shock and awe’ value. This is what sucks people in. My question is what’s it like to work in when it’s a large, long-running codebase, multiple developers, etc. ROR sucks people in because you can prototype really fast, and again that makes it impressive when watching demos etc. There’s nothing cool looking about demonstrating how a well architected java or .net app makes working in a multiple developer, large code base scenario more managable. That’s just boring but which does a particular client need?

As far as I know, ror isn’t a strongly typed language which presents some major issues. In the end, if I was building an application that I wanted to have staying power, ie I plan on the codebase lasting a while, then I would use java or .net along with a whack of available frameworks like spring, hibernate, etc to accelerate development time. In that light I’m not sure ror has much of an advantage. If you’ve never used those frameworks or a good O/R mapper then ror would be even more impressive because that’s a big piece of the shock and awe value you’re getting. I think the piece that impresses most people is it’s built in O/R mapper.

The real question is why? What does that CEO feel he’s getting by using ror? Cheaper developers? Better technology? No licensing costs? Better scalability? Faster development?

“After my run with RoR, I played around with ASP.NET 2.0. My thought the whole time was similar … where are the blog in 2 min (or 5 or 10 or w/e the RoR demo was) demos on this? Cause really, its a whole lot easier with ASP.NET 2.0 than in RoR. Its practically no code – all the controls are drag and droppable. Now, the biggest thing is that when you want to come back and do a real app in ASP.NET 2.0 after the initial wowing, you still can! You are the ones writing the SQL statements for the data sources (with tools to make it quick) and caching is very easy to implement. A lot of the plumbing is there for logins, user management, site navigation, etc, etc. And with all of it, if you need to, the provider model is easy to customize as you like.

That definitely sounds biased but thats how I honestly feel about it: They’ve done good with RoR’s marketing (the “demos”) but beyond basics, it really disappoints. Not so with ASP.NET 2.0 – only thing is maybe someone should do the 2-5 min “demo” for ASP.NET 2.0.”

Above quote from comments here.

A developer primarily talks to the Quality Assurance (QA) team in a meeting about code they’ve written, the ‘how am I going to test your code out’ meeting. Outside of those rare meetings, developers communicate with QA mostly through issues in a bug tracker.

Every software release contains a certain number of bugs. It is generally assumed that the number of bugs is a function of the lines of code written.

This is an oversimplification resulting in the belief that the only way to reduce the bug count is to reduce new lines of code. The real formula is something far messier like:

Where E represents the working environment. This mess includes the personalities of everyone involved in building the software, the level of trust between those people, the state of communications, etc.

Once something is measured it receives attention. The bookkeeping, and counting, of bugs related to the software development process contributes to the myth of the first formula. Posting and fixing bugs presents the appearance of work accomplished regardless of the reality. The goal of most QA departments is to find and post bugs, not find, post bugs and work with the rest of the company to keep a similar bug from appearing again.

The vast majority of bugs could be caught during the development process. They’re not bugs as much as they are change requests, often related to usability or product consistency. I have yet to work somewhere that has an ongoing, explicit goal of decreasing the number of bugs per release? In other words, write better code. I don’t mean finding bugs and making sure they don’t go out in the release, that’s a given. I mean taking it a step further and using bugs as a means of influence to the development process itself.

Position QA less as a quality enforcement department, more as a learning department. Task both the development and QA teams with improving as a single group from release to release. In this scenario, QA and development are very much part of the same team. QA members don’t simply point out what’s wrong with a developer’s work, they talk to each other and determine where things went wrong and if there’s a way that it could be done better next time around. QA moves into a role of teacher and source of learning for developers. It’s not perfect but it’s a start. It demands a certain type of developer, ie one with less ego than most.

Unfortunately I don’t think this learning process can be a formal one. It must be left to the overall project team to find ways to learn from the bugs that were found and fixed. Mistakes become tools to get better as a team.

When it comes to software development, I’m against documentation. At first read of that statement, most techies should assume me to be a caveman developer. It should outright scare most software management types as most processes are about providing management a means of controlling the development process. This relies on the development team documenting their work in a way management types can grasp. That’s obviously a real need but let’s put that aside and assume that your real goal isn’t to control the process from outside but instead from within.

The need for development documents is a symptom of communication issues within the dev team. They perform other tasks like force you to actually design what you’re going to build. If you had a team who did that without documenting it, would it matter that it wasn’t written down?

My ideal development team, a completely unattainable ideal, would have no need for documents and every character they type would be actual code. I’m not referring to requirements docs or functional specs from the business team. I’m referring to documentation within the dev team itself.

The ideal team would be a Stanley Cup winning hockey team. They wouldn’t have to talk, there’s no need for verbal communication, they just know what each other is thinking, what they’re about to do, where they’re going to skate next. When they started the season they made mistakes and passed to open ice where they thought their teammate would be. As a hack, they started yelling out “drop pass” or “go to the net”.

The point is that the documents should never be viewed as the end goal because they never were. The end goal is working software. Most teams will always need some overt communication, never able to completely abandon it but the best reach another level.

Instead of looking at a dev team’s documents as unavoidable paperwork, try looking at them as hacks. Think about what could be done, in terms of team structure and dynamics, to remove the need for them. It’s like the stop sign at the end of your street. Our goal should be to take that sign down as we all now have the common sense, compassion, etc to stop our cars at that point.

Ok, like I said, it’s an unrealistic ideal. Do I ever see myself being part of a development team with no dev docs? No, it’s not realistic nor is that my point. Can we learn how to improve our team and how we go about building software by analyzing these “signs”? I think so.

Me too….well now I do…

“Whenever I created a web project in VS.NET 2003 the first thing I would do was delete the global.asax and its code behind, delete the AssemblyInfo.cs file (since it rarely makes sense to version your code behind assembly), open the web.config file and reduce it to a single self-terminating element , and finally rename the generated WebForm1.aspx file to Default.aspx, fixing up the corresponding code behind to match.”

We’ve been toying with aspects of Scrum for a while now with a few of our projects. If you’re picturing a bunch of developers gathered in far too intimate of a group hug then you’re thinking of the wrong scrum.

Someone recently asked me what exactly scrum was. Before I read the above wikipedia explanation I’m going to try to repeat my answer here. So you have eXtreme Programming, or xp, which is a methodology for building software. XP is often described as an agile or lightweight methodology. Methodologies are about how you build software. Scrum is a means of managing, or wrapping a process around, lightweight or agile methodologies.

What are lightweight methodologies? I often describe them as a response to traditional software processes such as the waterfall model. Traditional models try to freeze things. You start at requirements then at some point you freeze them and move onto design. Then you freeze the designs and move onto coding, etc. Sure the phases overlap somewhat but the ideal model is a staged one.

What you’ll quickly find in a traditional model is that it requires a certain level of delusion, or you all simply bs each other. The reality is that nothing is ever frozen, especially for the eight to twelve month release cycles products typically have. Lightweight models are a response to this delusion, or an attempt to bring it forward and deal with it openly.

Here’s what I like about Scrum today:

• It forces everyone to get real, real fast. The speed, quality and level of information for all stake holders in a software project goes through the roof. This is great, however, it does require attention as not everyone is used to, or wants, this level of information.
• It offers new levers to business owners. Business owners may be actual business owners or product management or a board. They are the non-technical people that keep poking the techies for releases. Typically the only real levers business owners have at their disposal are cash, features, and dates. A business owner will set a date practically at random as a means of incenting a team to work their ass off to nail that date no matter how reasonable. In scrum the business owner has the product backlog as their main lever.
• History. Scrum provides great tools to formally track how a particular team tracks over time. I feel they’re attempting to do this in a way that’s reasonable for team members to truly participate in. By truly participate I mean that scrum has attempted to build a model that team members won’t continually try to fudge or subvert. Over time you build a decent representation of how a team tracks and delivers. I’ve gone through every form of post-mortem and followup meetings you can think of and none have had any real benefit to the team members.

Now I’m going to actually read some of those wikipedia links above to find out how wrong I am about all this….

As defined in Solving Tough Problems, problems are tough because they are complex, and that there are three types of complexity: dynamic, generative, and social.

A problem has low dynamic complexity if cause and effect are close together in space and time. In a car engine, for example, causes produce effects that are nearby, immediate, and obvious; and so, why an engine doesn’t run can usually be understood and solved by testing and fixing one piece at a time.

A problem has low generative complexity if its future is familiar and predictable. In a traditional village, for example, the future simply replays the past, and so solutions and rules from the past will work in the future. A problem has high generative complexity if its future is unfamiliar and unpredicatble.

A problem has low social complexity if the people who are part of the problem have common assumptions, values, rationales, and objectives. In a well-functioning team, for example, members look at things similarly, and so a boss or an expert can easily propose a solution that everyone agrees with. A problem has high social complexity if the people involved look at things very differently.

So how does this apply to writing software? A few ideas come to mind.

Reduce dynamic complexity through designing simple, intuitive code and bring cause and effect as close together in code as possible. The goal being to quickly locate the cause (buggy code) when an effect is reported (bug).

Reduce generative complexity by leveraging concepts such as design patterns. Design patterns offer a way to use our past to solve our future patterns.

Reduce social complexity through hiring practices that allow teams to effectively vet new team members. Facilitate and stimulate the social networks within teams and realize how key they are to the success of your business. A lot of environments mistakenly view social events as goofing off when it could be the best money they ever ‘waste’.

What else?

So I still sit firmly on the fence when it comes to hungarian notation in code. I’ve experienced it misused so badly over and over again that I’m hesitant to commit myself again. You can look into it’s history here (link courtesy of Joel). I will, however, say that I love it when used on database table indexes.

I find that prefixing a table’s index with “ix” makes life so much simpler. The table named “User” has an index named “ixUser”, “Role” has an index “ixRole”. It’s quite clear when you’re looking at the columns for User that the column “ixRole” establishes a relationship to a table called “Role”.

Contrast that with the myriad of databases I’ve seen with tables filled with index columns named “index”. How does that do anything for anyone? Or inconsistent naming where some indexes are “UserIndex” while others are “RoleId”.

Obviously the important part is being consistent but the ix prefix is where I’m at today.