Code Renaissance is about building great teams and great software. By exploring best practices, team interactions, design, testing and related skills Code Renaissance strives to help you create the team and codebase that you've always wanted.

All architecture is design but not all design is architecture. Architecture represents the significant design decisions that shape a system, where significant is measured by cost of change. [Grady Booch]

My take on it:

I've worked on systems where every developer does their own thing. Highly interactive business web apps where there is no over arching pattern and everyone takes the path of least resistance... which is usually the way they did it at their last job or worse, whatever seems clever at the moment. These systems are pure hell to work on and maintain.

Every significant decision (ones difficult to change or make consistent later) is part of the architecture. From how you construct user controls, to what is done in code behind and what in javascript, to how you do ajax behavior... it's all architecture and it all matters. There must be a cohesive vision for how everything is constructed. The team must share and enforce that vision.

A lot of this comes down to communication. If someone is doing something that hasn't been done before on the project then they should grab a few team members for five or ten minutes and discuss it. Doing it right the first time is very important because one tendency of developers in a hurry is to simply see how things were done the last time and copy that. If the first set of code was bad you'll end up with six one off copies (each worse than the last) in a blink.

From what I've seen, the more developers have time to discuss the code and how things are constructed (and then run the decisions by their manager or architect for sanity check) the better and more cohesive the architecture will be over time. Peer discussions of architecture must be part of the culture. This means everything from new pages and new features to old code and refactoring. It doesn't have to be long and it doesn't have to be everyone together but small discussions must take place between team members throughout the day.

If developers share in the architecture of the system, if the own it and take pride in the architecture as a part of the team culture, then there will be little need for management to police it because the team members will police it on their own. New members, through peer pressure and team interaction, will quickly be indoctrinated into the culture and the team's pride in the architecture thus perpetuating the system.

As a coding exercise I decided to write a recursive algorithm to find prime factors of numbers. Why? For fun, learning, discovery, mental exercise... take your pick.

Among other things prime factors have cryptographic applications. Also it's a great way to increase your knowledge of a language... among other things I discovered that javascript floating point handles these calculations just fine but after 15 places some numbers have the last digit(s) become 0 e.g. parseInt("10000000000000000",10)+1 == 10000000000000000... it's the only floating point problem I found with this exercise. Other than that the code works well and the app below will factor numbers in real time as you type (and check the results to make they're valid).

Give it at try:

Enter a number to get it's prime factors:

As you can see it's pretty darn fast... results may vary but if you have a recent computer then there shouldn't be a noticeable lag on numbers up to 15 digit primes. Primes take the most calculations; they are verified by attempting division by 2 and then every odd number from 3 to the square root of the number being factored.

Using this method determining that 1243245576856897 is prime only needs 17629844 iterations which takes ~2 seconds on my laptop. 5467154436746477 only takes 5 seconds. If you did every calculation up to half of 5467154436746477, which is what I did at first, it would take a year to verify it was prime (assuming you could keep the javascript running that long).

The amazing thing is that the code that does this is small... This little recursive function does all the calculations: