Talking about testing code on live servers and options, such as a one-off (rename a page and no one will know that it exists - leave the older one fully in tact but tweak the copy or other page) or pulling code between branches as needed. Kind of some possible hacks, tricks, and tips.

Chuck did some show and tell on the view parts page and the parts usage pages. These are existing pages in the site. The new project is doing an upgrade and facelift on those pages. Both pages are being configured into a series of horizontal tabs. The old pages ran up and down and had a lot of scrolling. The new ones should be less scrolling and hopefully easier to use and navigate.

Lots of talk about how to handle custom code and custom projects from an independent developer type role and format. Yesterday there was some discussion and a small disagreement between Steve and I about how to handle these things. Tensions were high. Both of us are trying to make things happen. Chuck was talking about the need to put some rules in place for going forward. One of his comments was, he didn't think that it was fair for someone to be punished for moonlighting, if they are an independent. If they are an employee, then that might be different. However, our current model is setup to handle independent contractors.

Chuck had some good ideas on creating incentives and ideas on some of the rules that would help the process out. I asked him to put together a bulleted list of some ideas to get the discussion going and have at least a staring place. Chuck does independent work for a number of clients and different companies. Chuck kept saying that if a project is built on top of adilas, as a platform or system, then adilas should get a cut from that project. That is not in place at all at this time. He was mentioning IP (intellectual property) and how that is a company's asset and they should get a kickback if it is being used.

This is kind of funny, but Chuck said that he felt like a kid watching mom and dad fighting and trying to help out and find some common middle ground. He was pitching that we need an SOP (standard operating procedure) for how to handle custom projects. That would be good. We all need some standards and virtual limits or lines to be drawn. All of those things would be good to know. Especially, so that we don't get custom projects that get sticky in a bad way. We like it when clients like what we do and get sticky, meaning they want to stay around. If a project gets sticky, in a bad way, that is no fun. If we run all projects through standard processes, it will eventually help all parties involved. Good call.