A Pamphlet On Surviving the Web Development Wilderness
February 8th, 2010
3So here we are on the eve of a public beta launch for a project we have all been working extremely hard on. In a flurry of excitement and anticipation we have spent the last few weeks buttoning up absolutely every tiny detail we can to muster the strength and time for. My team is responsible for a web app interface (built on rails) to our new service. In the current push to get everything in order and prepare ourselves for the onslaught of real users we have been repeatedly telling each other how lucky we are that we have good test coverage and an excellent work-flow.
A financial adviser once told me “There is no such thing as luck, you either prepared for the future or you didn’t”. Being a Boy Scout myself this resonated with me. Being prepared allows you to take advantage of a good situation, like finding water at an oasis and having your handy water bottle in your pack. Being prepared can also allow for some self preservation in more critical situations, like packing an extra days worth of food incase you need to bivy in order to ride out some nasty weather.
So carrying on with the theme of Boy Scouts…
“The 10 essentials”
1. A clear roadmap
2. Easily understood and broken down iterative goals
3. An aptitude for not being attached to specific pieces of work and seeing value in practices and design patterns that might be outside of ones usual approach
4. A hunger for improving ones work; this can be seen in things like keeping up to date with recent changes, shifts, or discussions in your development community or by regularly attending local area meetups
5. Excellent testing habits (we prefer BDD)
6. Ability to communicate clearly and effectively
7. Ability to debug/ reverse engineer
8. Automated deployment (Chef, Capistrano)
9. A good text editor (TextMate, Vim, Emacs) and a shell of your preference (bash, zsch)
10. Reliable monitoring (GOD, New Relic)
Don’t forget…
Never travel alone, no developer is an island. Make sure there is always someone you can bounce ideas off of, don’t isolate yourself otherwise you might end up talking to Wilson and he will agree with all your bad ideas.
Understand that no tool, no suite of load tests, no super awesome piece of hardware will count as being prepared. You must be able to reach into your bag of tools at any given time and be able to face whatever foul thing may happen. JMeter might say you are ready but don’t sleep soundly unless you have seen your production setup handle all those requests from real traffic.
“Release early and release often”, do not deploy for the first time the night before your beta launch. You should deploy to a staging server on a regular basis; think of these as training hikes, this way when it is time to deploy to production things will be familiar and proceed smoothly since you have done it so many times before. Another aspect of this is that it allows you to get feedback on a regular basis, this takes some of the guess work out of the development equation.
Being able to adapt to change is more important than being prepared for a specific use case or perceived future problem (I may or may not be talking about scalability here). You will be a better developer if you can rapidly adapt to a current issue knowing it’s intricacies then if you were to spend resources solving a problem that doesn’t exist and you don’t know the details of. As developers we need to take extra care to manifest an ability to rapidly and accurately address current development issues without allowing fear to cloud our judgment.
While I am currently writing this from the perspective of a Boy Scout gone Rails Developer I believe these things are good rules of thumb regardless of what you code or work in.
But you want more juicy details don’t you? I suggest you subscribe to the rss feed since my team and I will begin to publish more detailed explanations and examples of our approaches in the upcoming weeks. Keep an eye out for these:
- Iterative project management with Pivotal Tracker
- Testing authentication with Cucumber
- Load guessing with jMeter
- Semantic HTML and playing nice with others
- Good design is not just for designers
Tagged with: web development, agile, ruby on rails, Kanban
Related Posts
Author
Jason Campbell
Jason is one of our lead developers and specializes in web development, his manner of relaxing requires large volumes of strenuous activity (mostly cycling).
3 Comments Leave a comment
I didn’t really elaborate on the fact that we are using git for version control and deploying our rails app with Capistrano. These two tools together afford us a lot of flexibility for cherry picking commits to revert, as well as allowing us to rollback deploys relatively easily.
Not as tight as having some kind of control panel to turn off broken features as you suggest tough…
trust me. build a maintenance config. you don’t want to go through the pain of doing stuff in source control when you can just toggle something. we use git as well, but it’s not the same.
Leave a comment
Allowed Tags
_emphasis_
*strong*
??citation??
-deleted text-
+inserted text+
^superscript^
~subscript~
@code@
Add code using a GIST
gist: gistid
one thing that’s missing is maintenance configuration. don’t forget to include a mechanism by which you can enable and disable features. that way, if something goes haywire, you’re not scrambling all weekend to bring the site back up, when you can simply turn off the broken feature.
Reply to comment »