CFObjective() 2008 - Day 2 - Selling Professional Development
How to get everyone else to use the modern development tools and techniques that you do. ;)
"Pragmatic Programmer"
Things we should probably use in the office:
Eclipse (with Aptana and Flex Builder) - With Aptana, I have officially and completely switched over to Eclipse.
Local Development - for full server control, general debugging, step debugging, speed, stability. All the peeps here consider a shared Dev server to be a bad thing.
Subversion - The CF community uses Subversion. Nobody uses Surround. Nobody has even heard of it. (http://tortoisesvn.tigris.org/ - Tortoise as an interface)
ANT (possibly) - For builds. Or even simply EAR packaging for build deployment.
CFCUnit - I really know nothing about this, but it comes up again and again in these sessions. It is just assumed that everyone uses it.
Frameworks - Possibly Model Glue for Phoenix. Since we are building from scratch, it might be valuable to invest the effort to learn and use a framework so we are all coding in the same way. This is difficult and initially painful, but it may pay off big time for everyone.
Tactics: How do we go about doing all of this?
- Focus on the specific needs and goals of your organization. Maybe we don't need to use everything above, but maybe just one or two can really help us improve. We don't necessarily NEED to use Model Glue, but perhaps generally adopt the MVC paradigm.
- Demonstrate - Create a demo or something that exhibits the benefits of the tool/idea.
- Focus on compromise and things that remove restrictions. The example here was an org that forced all SQL to be in stored procedures, but a dev wanted to use Coldspring. Coldspring uses cfqueryparam in its generated code, which solved the same issues that prompted the org to adopt their stored procedure rule in the first place. All other devs were happy because they hated the stored procedures.
- Bridge gaps - Perhaps you can't get everyone to move over all at once, but you can make incremental changes.
Why is that exactly? How many of the peeps there have experience using a shared development environment, and what was the problem with it? How do they manage source control and local development, especially with a component driven development methodology? This would seem especially pertinent considering the suggestion to use a MVC framework where one developer could be working on the backend classes while another is working on the front end.
Are there many people there in a similar situation to ours? mid sized development teams with multi-product development?
Cheers,
David
I use a client called SmartSVN. It is a stand alone client (conceptually) similar to what you have with Surround. Odd that no one at the conference has heard of surround, especially considering how much advertising they did in CFDJ back in the day.
Subclipse is a popular eclipse extensions.
I had a hard time switching from Surround to SVN because a lot of the same names perform different actions. But, i'm very happy w/ SVN.
David,
When you are working on something, the application is often in a state of Flux. Lets say that Bob and Kitty have a shared development server. Bob needs to work on "Report 1" which is only available after an "Admin" logs in. Kitty is doing some development on the login code, perhaps to change what data is loaded when a user signs in.
Kitty's code isn't working, so Bob can't login to test your "report 1" changes. Bob sits around doing nothing for a day or two while Kitty works out her kinks.
With local development, and version control in place, this is not an issue.
Kitty needs to work out her code, so she creates a temporary branch (AKA Copy of the code), based on the trunk (AKA Current Version).
Bob needs to work on his code too. So he creates a temporary Branch (AKA Copy of the code), based on the same trunk that Kitty has used.
Both can work on their code, without being affected by each others changes.
Then Kitty finishes her changes, so she commits them to the repository and merges her branch back into the trunk.
Bob makes his changes, commits them to the repository and merges his branch back into the truck.
I would expect a company with 4 developers (like yours) would have problems like this expended.
Most likely a copy of the "trunk" will be on some staging server for people to test how it all works. Once you throw ANT into the equation, it's very easy to deploy / merge changes and the sort. ( or so I've been told, I haven't used ANT yet).
I've done 2 projects in the past year which had 3-5 developers working on them; and I used Subversion in a manner like this to great success.
If you can take the time, I Recommend reading through the SVN Redbook. It's a great overview on Version Control Techniques. Specifically read about branching, merging, and tags. ( http://svnbook.red-bean.com/en/1.4/svn.branchmerge... )/
The biggest problems with using a shared development environment come at the application level, or, say the index page of the site. If that is broken, then its hard to get to any other page. Proper development practice will mitigate this problem somewhat (i.e., not coding ALL of your app in one flowing index page!).
I'm concentrating on the sentence: "All the peeps here consider a shared Dev server to be a bad thing.", and I'm still wondering why? I can tell you from personal experience, across many positions, that when we didn't have a shared development environment, the quality of the software was not as good as when we did have one. Now, thats my personal experience, and my mind is here to be changed, but I'd be looking for a more detailed response that any I've heard in the past.
As for the actual source control tool used - no matter what product you use, if you don't use it in a consistently correct manner, you're asking for trouble!
Cheers,
Davo
I would assume (knock on wood) that the QA person has their own local development environment, just like the developers. After QA has "Stamped" it, it would go out the staging server for clients to review.
In larger projects I have heard of situations where there are dedicated QA servers in addition to staging servers and production servers. Although I do not work that way.
In an ideal world the developers will be writing unit tests, which will be run during development and after merging their changed branch back into the trunk.
One might argue that coding all of your app in one flowing index page is a good approach. In fact, most MVC frameworks that I've worked with route all page requests through a single index page, using that page as a front controller.
I think the reason why a shared dev server is a bad thing is stated by you: If the index page is broken by Developer1, Developer2 can't do anything until it is fixed. That was the same point of my "Kitty / Bob" example.
I've no problem with developers writing unit tests, as long as those are not the test cases being used by the QA engineers. No parent ever thinks their baby is ugly - it is the job of QA to break the developers code. If no errors are found by QA you either have amazing developers, or a deficient QA plan - I know where my money would be on that.
The idea of going straight from a local environment to production - or even a QA/Test server - is not what I would consider "professional development" at all. It may be cheaper, and it may work on small projects, but I just can't see myself trusting it to a complex system. At VERY least, you want to use environments that mimic your production environment - and that's something that is difficult to do locally (I'm not just talking code, I'm talking about the whole enchilada). A shared development environment is just a part of the process - before something is released to QA, it should be checked against the repository, given the once over by development and moved. That doesn't preclude local development, of course, and each situation is different - hence my question about whom made the suggestion, and were they working on the same kinds of systems we are.
Cheers,
Davo
I misunderstood originally regarding all code in one page. You are right, that would be horrendous.
I'm not understanding where a shared development server fits into the picture if all developers also have local development environments.
It most certainly can work, it does require developers to be more careful with their development, though (something we should be doing anyway, right?)
Cheers,
David