There are a few controversial ideas in Benjamin Sandofsky’s You Can’t Go Home Again, in which he basically says that Agile methodologies shouldn’t be used in mobile app development. I did find this perspective on QA interesting in our increasingly post-QA world:

Sit down with a software engineer from anywhere but the web, and ask them about QA. Tell a game developer you don’t need it, they’ll tell you you’re nuts. Maybe these agile people have been burned by bad QA, but a great QA team is far from a bunch of monkeys clicking buttons all day.

Formal QA provides a counterpoint to “move fast and break things.” Their job isn’t to say, “No.” It’s perfectly fine to ship bugs– otherwise software would never ship. You need someone who is aware of all the bugs, and help you make the decision if the risk is worth it.

Also see Michael Lopp’s The QA Mindset for some really good perspective.

David Cancel has some interesting thoughts on how they split up product management and tech team responsibilities in How we transformed HubSpot into a Product Driven Company. I really liked this part about embedded designers:

While we kept the core technical team tight, they were bolstered by the presence of embedded product marketers and UX designers all fixed on the same problem and solution. Designers and UX researchers informed the product teams from the point of mockups, through testing phases, to the ultimate release and support the product. […] The upshot here is that product teams become wholly self-sufficient organisms. They are small enough to retain customer focus but still have the skilled resources they needed to design, test and market the solutions they developed.

That post led me to Jeremy Crane’s What does a Product Manager do at HubSpot, which goes into more detail on the PM/Tech team split:

Every product team’s job is, essentially, to solve problems for their customers. Solving problems involves two key components: (1) Understanding the problem, and (2) creating the solution. At HubSpot the product manager owns the “problem” and the technical team owns the “solution.”  The “problem” is defined by whatever is likely to produce the greatest value to the customer and the business at large within the area of influence. The “problem” is both long-term and short-term in scope. It addresses the immediate challenges that the customer is experiencing, while still keeping an eye the longer-term vision of the product as a whole.

Huge thanks to Tower 2 for sponsoring the site this week!

Version Control is an essential tool in today’s web and software world and a fundamental part of the workflow in teams large and small.

We believe that version control with Git should be easy. And why not beautiful?

It’s not about the command line or a Gui. It’s about how to be more productive, avoid mistakes and make your life easier.

With Tower 2, we’ve worked hard to make the best Git client even better. Completely redesigned and reengineered, Tower 2 comes with more than 50 additional features, a brand new design and an outstanding performance.

We believe we’ve made a tool that helps you to become a better professional.

Download the free trial today and see for yourself.

Sponsored via Syndicate Ads

Maiz Lulkin has a great overview of one of the most important and most misunderstood issues in software development in his post Technical debt 101:

In software development, the dreadful consequences of sacrificing quality are widely misunderstood by non technical managers. They underestimate how detrimental it is to continued productivity and morale, and ultimately, to the overall strategy of the company.

He goes on to explain why…

In WordPress: How It Came To Be And Where It’s Heading Alex Moss interviews Matt Mullenweg and Mike Little, the two cofounders of WordPress. The whole interview is interesting, but their approach to technical debt caught my eye in particular:

We rewrite or refactor about 10 to 15% of WordPress in most releases, so that we can keep users getting updates and new features quickly, while doing the “ground up rebuild” incrementally in the background, fixing bugs and getting feedback as we go.

This is, in my experience, the best way to handle technical debt: pay down a little bit of it in every release. To steal a slide from my Product Management course, here’s my general rule of thumb (and of course there will be exceptions) for balancing a product roadmap:

Anthony Colangelo explains how he uses a technique called Switch Programming to help solve coding problems:

We gave each other 30 seconds to explain our intended results, and nothing else. Then, we traded computers and got to work.

I was working on a fairly new project with a codebase that Mark really hadn’t been in, and Mark was working on an old project that I hadn’t touched for over a year and a half (long story). Point is, neither of us were intimately familiar with the project we were debugging. It didn’t matter—we knew what had to happen, and we dug in.

Within five minutes, our issues were solved. We explained to each other what we did to fix the problems, we learned a little something, and we got back to work.

This sounds like a great approach to solve design challenges as well. If you’re not sure how to get past a particular design problem, explain the intended result to someone, and give them 5 minutes to try to sketch a few solutions. It will probably not be perfect, but it’s a great way to get some fresh thinking to bump you back on track.

Jeffrey Zeldman in a strong defense of web standards:

While many of us prefer to concentrate on design, content, and experience, it continues to be necessary to remind our work comrades (or inform younguns) about web standards, accessibility, and progressive enhancement. When a site like Facebook stops functioning when a script forgets to load, that is a failure of education and understanding, and all of us have a stake in reaching out to our fellow developers to make sure that, in addition to the new fancy tricks they’ve mastered, they also learn the basics of web standards, without which our whole shared system implodes.

I’ll add this to the ever-growing case for progressive enhancement.

Alex Maughan gives some great front-end design and development tips in his article Mobile-first, semantic, and modular front-end design. If any part of your work touches front-end development, I highly recommend this piece. In addition to walking through the tools he uses (and his reasoning), Alex also makes a strong case for progressive enhancement:

Designs should be approached with a content-first and mobile-first mindset. Following this, CSS breakpoints should always be mobile-first. All JavaScript should be progressively enhanced and should be used at a conscientious minimum where possible. Therefore, the concept of progressive enhancement happens from all aspects, from design to development and back again.

All of this translates into websites that are much more future-friendly within a disruptive device and browser marketplace. It also has the added benefit of improving performance and guarding against fatal runtime errors that stop pages from working.

I haven’t yet linked to many pieces on progressive enhancement. As I went through my Pinboard links just now I realized that 2013 has been a big year for this topic. These are all the articles I know about that came out this year in strong defense of progressive enhancement:

• Progressive enhancement is still important
• Progressive Enhancement: Still Not Dead
• Progressive Enhancement. Still Alive & Kickin’
• Progressive enhancement is faster
• A plea for progressive enhancement
• Progressive Enhancement: It’s About the Content

I don’t know, it sounds like it’s not dead yet…

Finally, I have a legitimate excuse for my obsession with sci-fi and post-apocalyptic literature. Apparently it’s going to make me a better designer. I’ll take it! Rebecca J. Rosen explains Why Today’s Inventors Need to Read More Science Fiction:

Once any sort of technology has users, it becomes extremely difficult to change it — even if you know it should or must be changed. […] How is that affecting our social structure and values? How is that changing the way we view ourselves and even the way we understand our own mental functioning? […]

Reading science fiction is like an ethics class for inventors, and engineers and designers should be trying to think like science fiction authors when they approach their own work. […] I feel with great urgency that we need to very thoughtfully consider what we build as well as encourage that same thoughtfulness out in the world.

So much has been written about the disastrous launch of healthcare.gov. But Sheryl Solberg and Michael Shear’s Inside the Race to Rescue a Health Care Site, and Obama hit especially close to home. Much of it reads like any number of software development projects I’ve been involved in over the years:

In Herndon, as engineers tried to come to grips with repeated crashes, a host of problems were becoming apparent: inadequate capacity in its data center and sloppy computer code, partly the result of rushed work amid the rapidly changing specifications issued by the government. […]

The website had barely been tested before it went live, so a large number of software and hardware defects had not been uncovered. Fixing the account creation software simply exposed other problems; people still could not register to buy insurance. A system intended to handle 50,000 simultaneous users was fundamentally unstable, unable to handle even a tiny fraction of that. As few as 500 users crippled it, according to people involved.

Rushed work amid rapidly changing specifications… No testing before going live…

Let him who has never experienced issues like that on a project cast the first negative blog post.