Richard Seroter’s 10 Architecture Tips From “The Timeless Way of Building” is highly relevant to software development as well:

“Each building when it is first built, is an attempt to make a self-maintaining whole configuration … But our predictions are invariably wrong … It is therefore necessary to keep changing the buildings, according to the real events which actually happen there.” (p. 479-480) The last portion of the book drives home that fact that no building  (software application) is ever perfect.  We shouldn’t look down on “repair” but instead see it as a way to continually mature what we’ve built and apply what we’ve learned along they way.

Just as buildings need “repair”, software takes iteration to get right.

Sticking with the theme of remote work, Steven Sinofsky wrote a great post called Why Remote Engineering Is So Difficult!? There’s a lot of food for thought, but here’s the main issue:

The core challenge with remote work is not how it is defined right here and now. In fact that is often very easy. It usually only takes a single in person meeting to define how things should be split up. Then the collaboration tools can help to nurture the work and project. It is often the case that this work is very successful for the initial run of the project. The challenge is not the short term, but what happens next. […]

If I had to sum up all of these in one challenge, it is that however you find you can divide the work across geography at a point in time, it simply isn’t sustainable. The very model you use to keep work geographically efficient are globally sub-optimal for the evolution of your code. It is a constraint that creates unnecessary tradeoffs.

Projects often start off ok, but then start to unravel as every small miscommunication and missed messages add up to a much bigger problem. I find this stuff fascinating not just because I work at Jive (where we don’t use email at all), but because we’re seeing such an explosion of remote work everywhere as our tools keep getting better and better.

Steph Yiu’s post Still figuring it out: communicating remotely with lots of people is another good one to read, since she walks through all the tools they use to get their work done. Our setup at Jive is very similar, except that we use our own tool where they use P2 (their Wordpress intranet theme).

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…