For HR and legal purposes, most development companies classify Software Engineers into ranks from 1 to 4 (or 5). The higher the rank, the higher the responsibilities, expectations, independence and pay grade. To cut it as an interviewer and manager, you’ll need to classify people accurately with a minimum amount of direct personal exposure: a non-ideal but practical requirement of most hiring processes.
So, how do you objectively identify senior engineering qualities? Preston Lee focuses on several key factors always present in quality engineers, independant of language and platform.
Identifying Senior Software Engineers: Six Critical Differences
Traditionally, there are two fundamental approaches when it comes to organising your development teams: the Architecture-Oriented approach and the Feature-Oriented approach. The first privileges teams that focus on the different architectural layers or components, whereas the second prefers to organise teams around deliverable application features.
How do you organise your development teams?
Karl Seguin has released the official, and completely free, Foundations of Programming eBook.
Although simplistic, every programming decision I make is largely based on maintainability. Maintainability is the cornerstone of enterprise development. Frequent readers are likely sick of hearing about it, but there’s a good reason we talk about maintainability so often – it’s the key to being a great software developer. I can think of a couple reasons why it’s such an important design factor. First, both studies and first hand experience tell us that systems spend a considerable amount of time (over 50%) in a maintenance state – be it changes, bug fixes or support. Second, the growing adoption of iterative development means that changes and features are continuously made to existing code (and even if you haven’t adopted iterative development such as Agile, your clients are likely still asking you to make all types of changes.) In short, a maintainable solution not only reduces your cost, but also increases the number and quality of features you’ll be able to deliver.
Foundations of Programming (PDF)
When it comes to testing, Cedric Beust (co-author of “Next Generation Java Testing”) lives by the following rules of thumb:
- “Tests first” or “tests last” is unimportant as long as there are tests.
- Try to think about testing as early as possible in your development process.
- Don’t listen to people who tell you to write “the simplest possible thing that could possibly work”, also known as YAGNI. If your experience tells you you’re going to need this extra class in the future even if it’s not needed right now, follow your judgement and add it now.
- Keep in mind that functional tests are the only tests that really matter to your users. Unit tests are just a convenience for you, the developer. A luxury. If you have time to write unit tests, great: they will save you time down the road when you need to track bugs. But if you don’t, make sure that your functional tests cover what your users expect from your product.
- Don’t feel bad if you are not doing Test-Driven Development. There are a lot of factors that make this practice a bad fit for a lot of projects and developer personalities (aspects which are very often never mentioned by TDD extremists).
From TDD leads to an architectural meltdown around iteration three, by Cedric Beust.
This article describes an example of how to handle version control in an agile environment with multiple teams. It’s not primarily targeted for version control experts, in fact such experts probably won’t find anything new here. It’s aimed at the rest of us, those of us that just want to learn simple and useful ways to collaborate. It may be of interest to anyone directly involved in agile software development, regardless of role, branching and merging is everybody’s business, not just the configuration manager.
Version Control for Multiple Agile Teams, another great article written by Henrik Kniberg.
A programmer cannot be Agile if the person that manages him is not Agile as well, and vice versa. That’s why Scrum focuses on management and organization practices while XP focuses mostly on actual programming practices, and that’s why they work so well together.
This excellent free book aims to give you a head start by providing a detailed down-to-earth account of how one Swedish company implemented Scrum and XP with a team of approximately 40 people and how they continuously improved their process over a year’s time.
You need to register to download this book, but believe me, it’s worth it!
What does Google, Sun Microsystems, HP, Amazon, Oracle and Motorola have in common? They all use ScrumWorks, an Agile process automation tool that enables teams to self-organize and maximize productivity.
“The best compliment I can give to ScrumWorks is that my staff doesn’t think about it. It is intuitive and respectful of the Scrum methodology, and easily becomes a very natural extension of the methodology.”
ScrumWorks features include:
- Product Backlog and Release Management
- Categorization of Backlog items using Themes
- Sprint Task Tracking for Teams
- Impediment Tracking
- User and Team Manager
- Excel Import/Export
- Web Services API
- Automated and Manual Database Backups
ScrumWorks is used by over 50 of the Fortune 100 companies.
Download SrumWorks Basic (free edition)