by tasha
Yardwork and Software Craftsmanship
Brandon Beacher talks about software craftsmanship and how diligence ensures a quality product.
Check out our related blog posts:
Posts tagged with Keeping It Simple
You are browsing posts about Keeping It Simple. Check out all posts on our blog.
by pamela
The Two X Factor
Last weekend, I participated in Rails Girls, an event that introduces women to development in Ruby on Rails. This particular event was held in Washington D.C., a hotbed for the tech industry.
As a Rails Girls DC coach, I cheered on the girls as they worked through building a web application, and lent a hand when a little help was needed. There were several other coaches, and more significantly, several other female coaches. While I anticipated enjoying Rails Girls DC, I didn't expect that I would be so encouraged and excited by working with others at the event.
→ Read More
Building products as a Highgroover and a co-founder of Body Boss has taught me that saying "No" to scope creep can mean the difference between a bloated, unfinished project and the successful release of an MVP.
As a former Big 4 consultant, I was taught that scope creep is ugly, and a supervisor once told me that it in an ideal world, it should never happen.
→ Read More
About three years ago, I worked at a product company where the central functionality in our app consisted of five or six domain models with excessive callbacks. I often found myself attacking the knotty nastiness for days at a time, trying to track down stubborn bugs.
Some time later, I stood up in front of the crowd at the Atlanta Ruby User's Group and said, "I hate callbacks! What good are they?"
Today, I have the answer.
→ Read More
by jonathan
Never use Resque for serial jobs
A long time has passed since we've last spoken about processing background jobs. Much has changed regarding the tools for asynchronously processing long running tasks in Ruby and Rails. Most recently we've favored Resque, especially now that Heroku's cedar stack supports it.
There's one problem with Resque. Enforcing strictly serial job semantics is impossible in Resque without custom development or limiting the number of workers.
So, NEVER use resque for serial jobs, OR read on to find how we resolved this dilemma with resque-lonely_job gem, a new resque plugin.
→ Read More
by david
Slide-decks the Web 2.0 way
At Highgroove we love giving presentations. We sponsor the Atlanta Ruby Users Group (ATLRUG), we each attend at least one conference per year where we are highly encouraged to speak rather than simply attend, and we give weekly tech talks at the office. Each Highgroover has their own presentation tool-stack ranging from extremely simple using nothing more than a web browser with various tabs they manually rotate through, to sophisticated Keynote slide-decks. One can also use a very editor and CLI-centric collection of tools to build flexible presentations using many of our everyday tools like git, guard, slim, and Github with Github Pages. If you like using those sorts of tools to speed things along read on after the jump.
→ Read More
At Highgroove we really like testing and are constantly looking for ways to improve our testing process, how quickly our tests run, and how exactly we execute our tests. How often during your Test Driven Development (TDD) cycle do your tests fail "mysteriously"? You've written your tests, written your code, and most of them pass but one or two stubbornly fail even though you are fairly certain they should pass given the testing setup you've provided? At Highgroove we bias towards action so we are likely to launch a debugger session or a pry session to get to the bottom of this. Another approach, which won't break your existing TDD workflow, is to use your test-suite in place of a more traditional debugger. After the jump we'll talk about how we've been using this strategy to dig into code quickly and easily.
→ Read More
Anyone that knows anyone at Highgroove knows we're not your run of the mill rapidly growing Ruby development shop. We're a unique team of creative individuals bent on productivity hacking and iterating on client needs until the app is awesome. Sure we've got some great perks and compelling reasons to make the commute into the office despite being a ROWE. What do we do at Highgroove as a group to intentionally keep our culture cool/unique as we continue to grow? Read more to learn about we stay keep our groove at Highgroove.
→ Read More
Meetings. Quick chats with our customers, daily if possible, don't count as meetings. They keep everyone on the same page to make sure good progress is being made for them, to address any questions or concerns they may have, and possibly to plan the next steps to take in developing their app. By "meetings" we mean that word that brings dread to the heart of anyone who has ever looked at their schedule and seen only two hours of their daily schedule available for actual work, and in fifteen minute blocks no less.
At Highgroove we have a few tactics for avoiding just that. Firstly, we don't have many. Moreover, all meetings are optional, and you can come and go as you like. A quick glance at my calendar shows vastly more pairings, personal trainer sessions, hack nights, team dinners, and other informal team outings than it does meetings. We consider this a win. Like all companies we still need some variety of status updates, the kind of subject matter that would usually go into a weekly company or organization meeting. To address that need we "bring it in" for the weekly huddle emails.
→ Read More
by aubrey
The Highgroove Test
Prior to working at Highgroove, I worked for a number of softare product companies. One of the best metrics I've found for measuring how great a company is to work for as a developer is the Joel Test, which is a list of 12 simple questions. I've worked at companies that have scored high and companies that have scored low, and please believe me when I can tell you that the issues on that list really do make a difference.
My only issue with the Joel Test is that it is really geared toward software product companies. While a lot of the ideals translate to a software consulting company, the specific questions don't always apply when you are working on a lot of projects for a number of clients. So, in an effort the help measure what makes great software consulting teams so great I present...
→ Read More
by chris
Refactoring: where to draw the line?
Refactoring is a something we spend a bit of time on at Highgroove, so much that David recently wrote about refactoring and related tools in Red, Green, Refactor and I'm writing with even more on refactoring and the 'Refactoring Rabbithole'.
"When refactoring, it's easy to see 10 other things that probably should/could be refactored"
Spending time on refactoring is a tough sell to clients: by definition, the 'backend' can be completely re-done without any visible changes in an application. As the complexity and size of a project grows, refactoring can be necessary to keep things as simple as possible, keep the code quality high, and keep the number of bugs low.
→ Read More
by brian
Writing Readable Ruby
Ruby inherits the philosophy of "there's more than one way to do it," or TMTOWTDI, from Perl. Of course, TMTOWTDI is worthless unless at least a handful of those ways can be written clearly not just for the author, but (perhaps more importantly) for future readers and editors. So, how do you make the best use of the many ways Ruby and Rails allow you to do things?
→ Read More
It's easy to say "We're agile" and "We use Behavior/Test Driven Development" and thus "we use the right tools to empower our developers!" but what are those tools? For me that discussion is entirely about the tool stack you choose, how that stack empowers you as a developer to do things right the first time. Luckily thanks to the ruby community as a whole we have a large number of high-quality choice to choose between.
→ Read More
by drice
Simple Design, the Highgroove Way
Highgroove Studios has taught me a lot about Software Development, Consulting, and building new web applications. Apart from the myriad of technical skills I've added since I came on board, Highgroove is a fantastic company to learn how to build your own web apps, how to design them, and how to remain focused on the most business critical aspects of the system. Highgroove taught me these things by adhering to a process which manages Agile development, responds to changing software requirements and business needs, and encourages constant communication. While these are all noticed by clients, there is one part of the Highgroove process that goes largely unseen; however, it is just as integral as the former three. That behind-the-scenes aspect of the Highgroove development process is keeping the software as simple as possible to meet current demands.
→ Read More
by pamela
Accept/Reject as you go!
At Highgroove, we like forward momentum. This means that we know that every delivery cannot be perfect, so instead of worrying about perfection, we worry about progress.
→ Read More
At Highgroove Studios, we're hyperspecialists in Ruby on Rails web application development. Not only do we write amazingly complicated code on time and on budget, but we follow up all our work with tests so we know our code works.
This is not without its problems however, as a test suite can become just as bloated and difficult to update as the code base it tests! This week, I'll talk about some of the ways I've learned to approach writing tests.
→ Read More
by jonathan
Debugging Best Practices
At rubyhoedown, the inimitable Jim Weirich gave an awesome presentation on using the debugger in ruby. Before his new found respect for the ruby debugger, Jim told us that puts statements worked just fine for him.
And this is true. You can get by with puts. But, you can get by much faster using the debugger. Read on to find out when to use the debugger and how.
→ Read More
by mike
The Great Campfire Experiment
At Highgroove, we like using the right tool for the job, but we also don't like getting too bogged down in thinking about what we should use. We recently switched our internal company chat from Skype to Campfire, but it wasn't a just simple switch to flip.
→ Read More
So you've got an awesome web application up and running. You want to keep your users engaged. You could try to handle collecting emails, writing your own newsletters, managing the list, keeping content fresh, tracking who read your messages, and so on (and so on) -- all within your own app; however, there's a better way. We recommend using Mailchimp. It's actually very simple to integrate Mailchimp into your own Ruby on Rails application. Quick. Easy. DRY. Just the way we like it.
→ Read MoreJeff and Tim at The Pragmatic Bookshelf wrote a great blog post on "The Only Agile Tools You'll Ever Need" which reminded us that it's been a while since we talked about tools here.
At Highgroove, we love our tools. We blogged about 'Trusting Your Tools' almost a year ago, and then about some of the other tools we use later that month. We're still using Pivotal Tracker, Github, Skype, etc, but there's a lot that has changed.
As much as we'd like them to be, all tools are not necessarily awesome, and Jeff and Tim's criteria for picking which tools to use is spot on. We've tried out a lot of things, experimenting with new tools and 'failing fast' (something else we love to do so we don't waste time) when something doesn't work right. It's pretty easy to get used to using something that is inefficient, or to spend all your time tinkering with new tools and gadgets and not getting any actual work done, so it's important to consciously bias towards simplifying your toolset. Here's some examples of things that we tried and scrapped.
→ Read MoreEvery programmer has had this thought: “Just 15 more minutes and I’ll have that feature working!”. And 15 minutes come and go, and before you know it its been an hour and the feature still isn’t working ideally. In fact, you’ve skipped lunch and have accomplished far less than you had hoped?
Why did you sit there for so long only to give up and probably get a late lunch both hungry and frustrated? Short and simple answer: You didn’t hold yourself accountable for your time and you did not let yourself have a good break!
by jonathan
A SQL Pattern in Rails
Edit: Updated gist to fix SQL injection. Thanks to all the code reviewers, uh I mean commenters, for pointing it out!
Wed Jun 29 13:55:27 EDT 2011
At Highgroove, we’ve been consulting on software projects since 2006. I can tell you that it’s been a long, hard learning process on how to sell service based consulting. We’ve certainly come a long way in helping our clients be happy about the services we provide.
by chris
Dirty Forms
When building fancy AJAXy apps that have complex user flows outside of page navigation, it’s important to let users know if they are about to trash something they just wrote. Ever had a browser lose several paragraphs of text you typed in? Not fun!
This can be done as complexly as you want, but at Highgroove we’re big fans of KISS so here’s a simple approach to making this happen. It assumes you’re using jQuery, but the same technique should work with any other JavaScript framework.
by emily
Keeping It Simple
Unlike almost every other geek, I only want one monitor. When I sit down at a desk with a monitor, the laptop’s lid gets closed. For me, it works better to keep things simple. In fact, there’s usually only one window showing on my one monitor. I’ve found through a few months of experimentation that the fewer distractions I have visible, the better I’m able to focus. It seems obvious now that I write it out, but it was a hard thing to figure out in a culture of pervasive multitasking.
This discovery has prompted a lot of changes in my workflow. I installed Spirited Away and use it almost constantly so I don’t have to think about only keeping one window open. Instead of using Freckle’s built-in timer for tracking my work, I use Tictoc so my timer is visible. That’s one thing that should stay in my face! Last but not least, whenever I can, I use paper.
When I’m meetings with clients, I’m taking notes in a paper notebook. I find it easy to write and listen at the same time, but switch to typing and I’m lost! While I’m working, I’m constantly taking notes: how wide each of those columns needs to be, questions to ask the client, potential bugs I’ve found. It’s all in the notebook. I’ve even been known to write code on paper when I’m trying to plan out a solution to a bigger problem.
These techniques are things I’ve discovered by constantly iterating on how I work. I pick something to try, and I run with it. Sometimes I discover a great new way to work and sometimes it flops. But without constantly seeking ways to improve, there would never be any progress.
What techniques do you use to help get things done?
by cbq
Less Code is Better
It’s a good thing we don’t charge by the lines of code we write in an application.
On a recent project, we’ve been keeping track of the lines of code, and it’s continually going down. You may be thinking — how is the project progressing? With less code, is the application doing less or providing less functionality?
Quite the opposite, actually.
A Post by Erik Huddleston RIP: The Iteration 19?? – 2010 came across our desks last week, and it sound’s like he’s pretty serious in thinking that Iterations are a thing of the past. Please give his post a read before you continue onward here. You might also want to look at CBQ’s posts on Iteration Based Contracts and What Makes a Successful Iteration, as well as mine on Communicate early, Communicate often, but don’t repeat yourself!.
Erik should definitely use whatever tools and methods work for him, but at Highgroove, we love doing iterative development, Pivotal Tracker makes it easy to get it right, and we wouldn’t have it any other way! First up, some rough thoughts from some other team members:
They sound like they adhere to a script even when it isn’t working.
Adopting a “pattern” for the sake of using patterns has never been a good idea. Being an “Agile” developer is more about being Agile with your processes than using “Agile” processes.
They’re just abusing developers in another way and finding another way to make them miserable.
If something is forced on a team that makes people unhappy, productivity will go down and quality will suffer.
They’re clearly in an environment where developers aren’t smart enough to accept responsibility.
Everyone on a team has to be willing to stand up for themselves and for doing things the Right Way. If a company culture or manager blocks out this kind of feedback, or developers aren’t willing to speak up, it’s probably a sign of an Office Space sequel in the works.
Some of those are a little coaxed and are a bit harsh, but I think the underlying feeling is pretty accurate. Here’s some specific counter-points to Erik’s arguments.
A little over a year ago, I weighed about 80 pounds more than I do today. Today, I am healthy, strong, energetic, happy, and more confident. Losing the weight took a lot of work, but that wasn’t really the goal, and it’s certainly not the end, either. The real motivation was to live healthier and be happier, and the real goal was (and is) always changing. To do this, I had to put lots of small choices into context: will this make me happier and healthier? Lots of small choices and small steps got me closer to my next, small goal. This, I realized, is a lot like how we approach “Big Projects” or “Big Goals” at Highgroove.
by jonathan
Cowboy/girl programmers don't live here
Have you heard the myth about the lone wolf programmer? Knee deep in crushed jolt cola cans, empty latte coffee cups, and busted keyboards (due to the incredible work rate of their owner), this paragon of unheralded genius is an island of productivity and impressive tasks accomplished in insanely short time spans.
The phe-nom rides under the nom-de-plume of the cowboy/girl programmer. And the cowboy/girl programmer doesn't work at Highgroove Studios.
You see, we code review.
→ Read More
by cbq
Working with Designers
At Highgroove, we’re not designers. We’re back-end Ruby on Rails experts. However, we love working with designers of all types: UX/UI experts, wireframing experts, PSD to HTML gurus and other hyper-specialists as well.
We love crisp, user-friendly interfaces that are simple, and straight to the point. When building a web application, it’s tempting to try to design out all the screens or flows that a user (or visitor) to the web application will see, but it’s practically impossible.
What inevitably happens when doing BDUF (Big Design Up Front), is that we all assume “that designers are able to foresee problem areas without extensive prototyping and at least some investment into implementation.”
For some web applications, “slapping on design at the last moment” can work (especially for internal-only, quick and dirty prototypes), but the best way to design a web application is Iteratively, on-going, while the application comes together (during implementation).
We’ve created a couple of documents and how-tos, internally, here at Highgroove to get smart designers up to speed on how to use version control systems like git (using the GUI interface, versus the command line), and how to design a web application that has ways to handle empty screens, error messages, etc. By getting Designers up to speed quickly and using light-weight tools, it helps us version HTML/graphic changes, and respond iteratively to both client requests (“can we make this smaller?”) and functionality requests (“can we simply add a ‘login as this user button’?”) to web applications.
Besides finding the perfect designer who is also the perfect developer (and also the perfect project manager and communicator and content writer and tester), what do you do to iterate on Design when building web applications?
Communication can be pretty tough, especially when people with very different backgrounds are working together to translate vague business requirements into a crisp web application. There can be e-mails, phone calls, Skype message, as well as messages that get posted to any of a number of project tracking services like Basecamp.
Without a plan, this gets out of hand really quickly. At Highgroove, we have a few very simple rules that help us get things done and deliver the best experience possible to our customers:
Pivotal Tracker is the authoritative source of information about every project
Most of our customers are pretty good about putting things that they want us to do into Pivotal Tracker, dragging and dropping them to prioritize what they want us to work on next. This is great because it keeps everyone in the loop and lets us look over past work and enables effective planning of when future work will be complete.
6am on a Sunday and you’re wondering about project status? Just open up Pivotal Tracker and you’ll know exactly where things stand, even if Matt has been up all night fixing bugs!
In fact, we’ve been using Github’s post-commit hook to update Pivotal Tracker stories automatically when we make changes to the code for a project. This means that when we fix a bug or implement a feature, a link to the details of the change automatically appears in the comments for that story.
That said, using a software tool can be pretty impersonal, so on to our second rule…
Contact us!
Talk to us on Skype, e-mail support@highgroove.com, or call us at 678.248.2440 any time you need something related to your project (or just to say hello!). We love to hear from you, and we’re here to answer questions and make changes to the plan for your project.
As soon as you get in touch with us, we’ll pull up your Pivotal Tracker project so we know exactly where things are. We put anything you ask us to do in a a Story, and tag things that we need something from you on with “needs-input”. If we answer questions for you, we’ll include the question and answers in the description or comment of the related story in Pivotal Tracker so that it’s easy to find again.
That’s it!
Everyone has their own preferred method of communication, so pick your favorite and get in touch with us. We’ll keep Pivotal Tracker updated with all the details so you’ll know that you’re getting what you’re paying for. If you decide that getting your pillow-pets ecommerce backend up and running is more important than fine tuning your space probe launching system, it’s just a drag and drop or a carrier pigeon message away.
by chris
Glue, Facebook, and Twitter
At Highgroove, we’re experts at glue. Not that kind of glue, but the kind that connects one technology to another.
We build on lots of great Open Source tools and libraries to deliver finished products to our customers that do exactly what they want. Without these pieces, we wouldn’t be able to do what we do.
For a project I’m working on right now, we need to be able to post to Twitter and Facebook on a schedule from within the application without requiring the user to push that ‘share’ button. The end result is something that seems like just two clicks in the UI, and isn’t much code, but took some thinking to get it working right.
So here’s what I put together, for you, for free! To those of you that put together the APIs at Facebook and Twitter, and those that worked on the Twitter gem and the OAuth gem, Thanks!
All the details aren’t there, but if you’re familiar with Ruby on Rails and working on a Rails 3 project, the code snippets there should be enough to get you talking to Twitter and Facebook. Let us know if you build anything cool based on those!
by chris
Nephophobia
nephophobia. Part of Speech: n. Definition: a fear of clouds. Etymology: Greek nephos ‘cloud’. – dictionary.com
If you haven’t been completely overwhelmed with the hype surrounding Cloud Computing,
chances are pretty good you are living under a rock (and not reading this blog!). Here at Highgroove, we’ve avid
users of the cloud because it lets us spend our time building kick-ass Ruby on Rails apps instead of replacing hard drives in servers.
That said, there is something pretty suspicious about the cloud. I’ve always owned servers at a colo as it is reassuring that I can go kick/hug them as needed. If something breaks and drops off the network, my datacenter is a short bike ride from my house and I can be on a
console in a few minutes. All that Amazon will tell you about their cloud is that they have a few datacenters
in a few different places, and that your virtual servers could drop out of existence at any time without warning!
Working at Highgroove, my fear of the cloud has somewhat dissipated. Chef lets us quickly and easily
spin up servers in the cloud. Seriously, it’s a one liner:
knife ec2 server create "role[super_sweet_app_server]"
The vast majority of our customers are in the cloud on Amazon EC2, Rackspace Cloud Servers, Engine Yard App
Cloud, Rails Machine, etc, and most of the time everything Just Works. It’s easy to add capacity to heavily
loaded applications, and this approach lets us do agile things that wouldn’t be possible without the cloud like refactoring production architectures.
This is pretty nice! Until it isn’t…
I needed a couple of Amazon EC2 instances last week for a project in a particular availability zone, and it was out. That fancy one-liner knife
command refused to run, and no additional capacity was available there for getting done what I needed to do. I had to push back that project, work on
something else, and it took over 24 hours for capacity to become available again. Faster and cheaper than buying new physical servers, but it’s pretty
frustrating when you’re used to instant gratification.
Also, with Amazon and some other providers, there is no guarantee that your virtual server won’t just disappear. This is a blessing in disguise
because it forces you to architect applications in ways that tolerate failure, but for small customers that only need one lightly loaded cloud server,
the cost-benefit equation doesn’t always allow it.
My Nephophobia is mostly in remission, but I’m not selling my rack of servers any time soon.
by mtodd
Knowing How To Solve Your Problem
It’s late Friday afternoon, I’m angry at this problem I’ve been working on for an hour (or more), but I’m stuck. The sun is out and a cool breeze is blowing softly outside and I want to be riding my bicycle through the streets of Atlanta at full speed! Right now, I can think of nothing more than how much I hate this bug. I’m stumped.
What do I do?
by jonathan
"The Vision of a Tester"
I recently completed my first sprint triathlon. The feeling of accomplishment
was overwhleming and I almost cried crossing the finish line. For those not
familiar, a sprint triathlon consists of a 400m swim, a sixteen mile bike ride, and
a three mile run in that order. Numerous volunteers provide water, gatorade,
directions and most importantly, moral support and kind words along the
course. I’m unable to overstate how welcome and vital words of encouragement
are. “You can do it!” “Great job! Keep it up!”.
As overlwhelmed, exhausted, accomplished, and inspired as I felt crossing the
finish line, a more inspiring moment came later, much much later. And it also
helped me answer the question “Will I compete again?”
A friend recently asked us, here at Highgroove:
“I am wanting to get into Ruby and Ruby on Rails development — what tools should I use, so I can start with a leg up?”
It’s a great question, and once we answered, our friend said: “you should put this on-line.” So here goes…
by jonathan
Trust your tools
As relatively new parent, my oldest is about to turn five. I’ve attended enough young kids’ birthday parties to develop a standard rating system for a
successful party. My rubric is simple and effective.
- Do they serve adult beverages?
- Do they serve adult food? (burgers = good. steak = better. no food? it better be a short party)
- As an adult, do I get cake?
- What about ice cream?
Its a simple system and it has helped me plan my own kids parties.
Good projects work the same way. A simple set of guidelines, when followed, insure success. Of all project guidelines, effectively managing scope is the most important. Pivotal tracker, our agile project management software of choice, keeps us on the straight and narrow when it comes to delivering value to our clients. This point was driven home for our recent work on a client’s project.
by cbq
Dealing with Downtime
One of our client’s web services (an API) experienced some brief downtime recently, related to an error on our part in rolling out some new data.
Things like this happen — they’re inevitable when dealing with even simple APIs and web applications. But, it’s not the downtime itself that is the main problem, it’s the communication of the issue, the solution, and the future prevention that are more important.
A first draft of our e-mail to the client had a sentence like this:
“Our sincerest apologies for this service hiccup, we always strive for the highest quality products and services and feel terribly when something like this occurs.”
This was quickly scrapped, since this sentence:
- is totally not our style. We prefer simple, clear communication, and this has a lot of fluff.
- doesn’t really say anything. It sounds a little market-y, and that’s not our job.
- doesn’t contain any details about what what happened or the solution, or how we will prevent it from happening again
Instead, we just simply outlined 3 main points:
- what caused the issue
- what we did to solve it
- what we implemented to prevent this from happening (a Scout plugin!)
Much better, don’t you think?
The NYTimes.com had a fantastic article this weekend on The Rise of the Fleet-Footed Start-Up. Here at Highgroove, we have been preaching about being lean, building products agilely, and doing more with less for quite some time. It’s great to see a piece in the NYTimes.com Business section advocating this now-proven successful model.
…the lean playbook advises quick development of a “œminimum viable product,” designed with the smallest set of features that will please some group of customers. Then, the start-up should continually experiment by tweaking its offering, seeing how the market responds and changing the product accordingly.
Ready. Set. Iterate!
by cbq
The Rapid Feedback Loop
One of the best features of Ruby on Rails development is the “Rapid Feedback Loop” that allows developers to quickly make a change and see right away how that new feature, enhancement, (or bug fix) behaves and looks in real-time.
This Rapid Feedback Loop actually becomes even cooler when you loop in the client — the product owner requesting a new feature or enhancement. At Highgroove, we do outsourced development and feature additions for many different projects. We’re always looking for ways to enhance that feedback loop with our clients. Here are few tools for quickly enabling an even more rapid feedback loop, that we can’t live without….
Here are 4 reasons for prototyping applications first. By prototyping, I mean an emphasis on building working applications rapidly:
1. It is much easier to edit an existing application that to try to dream one up with nothing visual and interactive to work with.
2. Too much planning leads to over-complication. Sometimes you can be too smart for you own good. “What if the user wants to do X or Y.” Don’t guess, find out.
3. A working application that can be tweaked beats a theoretical application that is perfect (and either sucks when it’s “done” or never sees the light of day)
4. A Prototype forces you to focus on the core functionality, that makes or breaks your idea. Trust us, the logo is not your killer feature.
Credit is due to our good friend Mike Landman of Ripple for Reasons #1 and #3.
by kevin
Keeping it simple the 8-bit way
Recently I bought Madden ‘09 for Xbox 360. I enjoy the game well enough (though seeing how I finished 11-5 with the Detroit Lions I now question its authenticity"¦) but can’t profess to have nearly as much fun with Madden as I did with 1991’s Tecmo Super Bowl
for the original Nintendo. The reason is a matter of simplicity.
Madden encourages the player to take the reigns of an NFL franchise or player, and often gets lost in the details by requiring too many off-the-field decisions and too complicated in-game button combinations. Of course the graphics are amazing, and online league play opens up a world of possibility never-before-seen in sports gaming, but when it comes down to actually gameplay, an element of pick-up-and-play gets lost in the complexity.
Tecmo is fun, plain and simple. No trades, no draft combines, no adaptive A.I., no bobbled catches, no user activated celebrations, no booth commentary or virtual trainers.
Just two buttons on the controller, eight plays to choose from on offense and one formation on defense, a trick move that’s unstoppable if executed correctly, and perhaps the most addictive gameplay this side of Tetris.
The contrasts between the two games remind me of something that’s often forgotten while developing software "“ the end goal. It’s easy to get wrapped up in feature-itis, in making applications too complex for their own good. But software that’s easy to use and sticks to its principle function is almost always the most productive.
by derek
Looking for insight? Skip the coffee
It hurts – it feels like giving up. You’re stuck on a problem and do the last thing that makes sense – stop thinking about it. And the minute you forgot about the problem the solution comes into focus. Sometimes it’s a shower, for others it’s a long walk or playing a video game.
The Eureka Hunt – Why do good ideas come to us when they do?, an article by Jonah Lehrer published in the the July 28th issue of the New Yorker, covered scientific research on moments of insight. There were a couple nuggets on provoking insights:
Simmer down the focus.
Avoid things that help you focus (like caffeine).
If you’re in an environment that forces you to produce and produce, and you feel very stressed, then you’re not going to have any insights…Concentration, it seems, comes with the hidden cost of diminished creativity.
John Kounious, Cognitive Neuroscientist, Drexel University
Set the alarm clock a few minutes early
The drowsy brain is unwound and disorganized, open to all sorts of unconvential ideas. The right hemisphere is unusally active.
Get in a good mood
Jung-Beeman’s latest paper investigates why people who are in a good mood are so much better at solving insight puzzels (On average, they solve nearly twenty per cent more C.R.A. problems.)
by derek
Doing it your way
You need to be in the Bay Area. You shouldn’t be in the Bay Area.
You need to work crazy hours. You shouldn’t work more than 4 days a week.
You need to raise as much money as you can. You shouldn’t raise money.
The topics above never seem to get old and I think it’s unfortunate.
Just run your business the way that feels right. The majority of your time during the week is spent working. Whether you’re working for yourself or for someone else, if you’re not working the way you want to, it won’t last.
If you’re just getting started with testing (and general test-first or test-driven development) in your Ruby and Ruby on Rails applications, you have a couple of choices.
You can go with Ruby’s Unit::Test, built right in to Ruby, and built-in to Rails with unit, functional, and integration test suites setup for you.
Or, you could setup Rspec with Mocha, and implement a form of testing called Behavior Driven Development or BDD.
Both approaches serve the same goal: better, tested code, easier code to maintain, and in general, just better practices.
My advice is to start with unit tests, and then move to Rspec later.
by james
When not to use technology
As technologists and especially programmers we are always expected to automate as much of any process as we can. In general, this is a good rule of thumb and I'm a big follower of that philosophy.
However, though it may be hard for us to admit, some problems are better solved with less technology. Let me give two examples I've run across recently.
First, let's talk about filtering spam. I'm sure this raise some eyebrows, but I believe spam filtering is a human's job. My reasoning is very simple: I have not yet seen a perfect spam filter, so it's a given that I will at least need to correct some automated guesses. Because of that, a recent project of mine has no automated filtering built-in. That's right, I'm doing it all by hand and I much prefer it to any other system I've tried.
My complaint here isn't against automated spam filtering. It you like the filters, by all means use them. However, think through your implementation very carefully.
My complaint is that most automated filters are built around the automated filter as the main focus and my corrections correcting it as a secondary concern. Even worse, some implementations don't really account for my need to make corrections at all. I'm glad we make things so easy on the computer, but that means we're inconveniencing me. That can't be right. If I must be involved anyway, I want my role to be as simple as possible.
When I designed my new spam filter, I started with that goal. The specific solution for it may be different for each of us: I want a page I can go straight to, check boxes for all messages, and a single button to classify them all at once; or I want to receive emails as they come in and I will reply to the spam messages to signal the software should eliminate them; or whatever. The point is that this is the right starting point. If you want to mix in some automatic filtering that's fine, but I found that just addressing this correctly in the first place reduced my spam stress enough.
Let's talk about another example. In one of the applications Highgroove is currently working on the "Create" step for a typical set of CRUD actions is a little tricky. You could design a system of forms around it and walk the user through the process, but it wouldn't be a great experience. It's just one of those edge cases where it's really hard for a computer to understand what is needed, but a human will get it in an instance and be able to provide just the right answer. Beyond that, the create operation will be super rare compared to everything else the application does.
How did we address this? With a good old fashioned phone call.
The user can go into the application and put in their create request, which includes their phone number and a good time to call them. With a quick call the human can ask all the right questions and build what they need while they have them on the phone. It's low hassle for all parties involved and gives the application that extra personal touch.
What will we do if the application grows so huge that this process becomes a bottleneck? Well, that's a problem we would just love to have! We bet we would be able to bring on another person to help with the extra load when we reach that point.
Don't let this post talk you out of writing any Rake tasks or other automations you truly need, but the next time you run into one of those problems the computer can't handle too well don't underestimate the power of a low tech answer. Perhaps the computer can help you do it better, instead of trying to do it for you.
