On the morning GoToMeeting session. I helped Russell get some login credentials for the data 0 box. He is going to be adding some new databases and PHP options for the WordPress part of the site.

Wayne jumped on and we chatted before the meeting. Some of his stories about growing up in Idaho. He also showed us some stuff that he has created in Mindcraft - a huge super detailed castle.

- He started with a question, is the world round? His answer was, it is round, and that is what I choose to believe. Sometimes we don't understand the who, what, where, how, and why. We just have to take the information and either choose to believe and/or challenge it. How well do you accept things at face value?

- Things that are true and obvious at one point in time, may change as things progress. The same is true with programming. It is ok to question things and even challenge the norm. Be willing to break the models. We talked briefly about building and breaking things and then doing that again.

- Why do you write code? Alan - it is like a puzzle and I like to figure out the pieces. When you finish the project, you can be proud of what you did and created.

- Sometimes we like to show what we did and/or finished - that is a form of motivation (external feed) - We also love to talk and show people who can appreciate and understand what things are and what it takes to make that.

- Eric - He likes to build things. He loves the design part of it and then seeing it come to fruition.

- Russell - Easy, pretty, and powerful. Making things easy for others.

- Programs and technology can really make or break a company.

- What are the downsides to programming? Unpaid time that needs to be spent, people who don't understand, unbillable hours, the unknown, underestimating needs and/or requirements. Feature creep, pioneering and making things that don't end up getting used, etc.

- Eric - He likes to bill by the hour. He swallows some of the cost and calls it his ongoing learning process.

- Testing and test driven design - what is the style to do that and how do you accomplish that? Sometimes we get ourselves into our own little traps. If we take some time, sometimes we can step back and look at things from a different angle.

- Why do we test and why do we write tests? Confidence. Being able to verify that it does what you want it to do... Reliable and secure... What about the design? What if you did test driven design? Instead of just writing code, you virtually think of the tests that it needs to pass vs just the plain action code. What is your vision?

- Start with a test, then write the code to pass the test. The test might be the scenarios and/or the steps we want it to take. Have a bigger vision, but be willing to test and design as you build the component pieces.

- Think modular code and being able to test independent pieces. Super complex code that isn't modular may be bad code.

- Lots of emphasis on style. Appearance, the way things are done, systems, naming conventions, consistency, flow, a set of standards, easy to follow, other people/developers can follow along, patterns, directions and verbage, etc. A familiarity or comfort level.

- What is our style? Wayne likes to spread things out, spaces, white spaces, lots of comments, lining things up for easy reading. There are also section headers and/or natural breakpoints. Wayne really liked to break up walls of text into tabbed sections. He liked to line things up and make it more readable. That really helps.

- Wayne is using TestBox (testbox) a component of ColdBox (coldbox) for his testing.

- He broke his code into setup, before, after, and tear down type functions.

- Unit tests - tests a single set of code in an independent model.

- Database calls may be expensive (bandwidth, speed, and traffic). We need a way to emulate and/or fake the database calls. That allows the logic tests to be performed without full access to the database.

- Being able to mock things up is a huge key. Can we send fake data through the existing tests.

- DAO (data access object) - This could be a real dataset from a database or a fake or mocked-up dataset. The key is that the test can run if the data is real and/or fake. Either way, it is still able to run. This may not go here, but Wayne was breaking up existing methods and almost making mini black boxes even within the functions themselves.

- Where do you do your error handling? Wayne was specific where the error handling was and also where it was not.

- Simulating real database calls with mockbox (mock-up data).

- Formatting the data before the data is returned. Help prep the data so that it is ready when presented to the outside.

- Test suites (a family of tests). Wayne set these up with a keyword such as testGetPermissions, testObjectInit, testSomeotherFunction. The key word was the string test on the frontend of the function name.

- They, the guys, started getting more technical and actually looking at code and going over some of the test scenarios.

- If you really go into full on test driven design and unit testing, you have to be to a certain level. Similar to project management, if you are not at a certain size, you could totally over do things. You need to match both the testing and the project management to the size of the application and the size of the project.

- One of the goals of this test driven design approach allows for multiple different developers to play in the same sandbox. It helps to check tons of inter-dependency relationships (functions calling functions or other dependent options). It also helps your own code and making sure that all of the different scenarios can still play through. So, instead of retesting each condition, you already have tests in place to help it be more fluid and have a good confidence level of what is going on.

- Code once and use many. Having said that, don't repeat yourself... that usually means that you are writing bad code. Wayne was showing how he often setup a valid object, and then he changed one param at a time. That made it easier to see what piece had changed. Efficiency and trying to simplify where possible.

- What are the tipping points? Too repetitive, too long, too many forks, too many switches, etc.

- Wayne, on purpose, was showing tons of different coding styles. His goal was to show that we could do it in any number of different ways. We just need to format the style to fit our company and then try to go from there.

- Test the code that you wrote, not the code that some other company wrote (such as Adobe or Microsoft or Java or something like that).

- Labeling and getting things organized. Try to group like things together.

- Copying and pasting is very natural. It is very helpful, but can really duplicate problems. It can also make things fail due to lack of going back through and cleaning things up.

- As you mature, as a company, you will really want to continue upping the unit testing and get use to test first, then code, test first, then code. Once things are in place, the future changes get easier and easier. Especially having good tests in place.

- Russell asked for a step-by-step video on how to create things and even some best practices on what to do and how to do it. Wayne offered some other URL's, references, and links that will help us. How to install, how to tweak, etc.

- Alan's question - How do we help independent developers to buy into this? They are already somewhat fighting us on basic code sign-off. What are they going to say and/or do if we force testing, unit tests, and test driven design? Wayne was saying that if you get it, it will really help with future skill sets. There was then some back and forth questions on where are we going and what are we requiring? Both Alan and Wayne were talking about things. Wayne is going to go back through and create the initial test sets and then we'll need to go from there.

- All of this will get easier as we go along.

- Wayne - without proper testing... Adilas will fold in on itself due to the weight of the codebase and number of virtual cooks in the kitchen. It will start fracturing and crumbling without the pillars and support system. The test driven functionality and design will end up being part of the culture.

- Alan - we currently have some mega functions, that do way more than they should... those are really hard to test. We need to break things down into smaller and smaller function and be more focused and/or encapsulated into specific functions.

- Wayne - by learning how to do test driven philosophy... it has made his job so much more enjoyable and fulfilling. This is a life style change for programmers.

- Alan - If we go with test driven design and development... that means more dreaming on the frontend. He then said, Brandon, you will enjoy the more dreaming part of this.

- Eric - testing is sometimes dangerous being left to the original programmer. Sometimes we need a separation.

- Eric and Alan - MVC (model view controller) stuff - We have replicated things over and over again... As we get things better and better, we'll get a much cleaner code set. He really wants us to start pulling things into smaller pieces where we can get to what we need without all of the extra weight that currently exists. Think of adilas going on a code diet... we could really cut some weight and become more efficient. All we need is that little bit of logic or that little bit of validation.

- Maybe moving trims (trimming functions) out of database queries and up higher in the process. Setup the trims higher and then use all of the trimmed values as part of the re-usage. Once it becomes correct, use that value. Otherwise you could get disconnects and possibly be passing different values to different pieces without even knowing.

- One of the main goals is maintenance and starting to reform this code and application in new ways. Making the code rewrite that much more possible.