How to kill an idea, or help it grow

It is far easier to kill an idea than to encourage it and turn it into a useful solution. Be on a constant watchout for putting down an idea too early without understanding the positive reasons for it being suggested. Hopefully you will see that there are many ways in which you can be constructive.

To kill an idea, say:

  • It’s not part of your job
  • That’s not what we do here
  • Costs too much
  • Against the company policy
  • It’s not budgeted, maybe next year
  • Let the other department handle that
  • It is not our problem
  • Why would you do something like that?
  • We have been doing it another way for a long time and it works fine
  • If it’s so good, why hasn’t someone suggested it already?
  • Has anyone else tried it successfully?
  • We have tried that before and it didn’t work
  • Is anyone crazy enough to try that?
  • We’re already doing that

To help an idea, say:

  • Yes, and…
  • Great, let’s try it
  • How can we make time to see if it will work?
  • What resources would we need to do it? Tell me more
  • How can we make it work?
  • What are the advantages?
  • How can we remove the dis-advantages?
  • What can I do to help this happen?
  • I like it
  • That sounds interesting, tell me more
  • How can we convince everyone else?

Leading a Software Development Team

36 steps to success as technical lead

  1. Define early on what success means for you, the team and the business.
  2. Believe in the project: idea, architecture, time, team.
  3. Understand the domain, the business requirements and the technical challenges.
  4. Know your team: strengths, weaknesses, ambitions and personalities.
  5. Have a plan as a result of a planning activity.
  6. Be part in the design of everything.
  7. Get your hands dirty and code.
  8. Act as a communication proxy for your team.
  9. Make sure everybody understands the big picture: their work has implications.
  10. Fight for architecture and design consistency.

Read more

How not to lead geeks

  1. Downplay training.
  2. Give no recognition.
  3. Plan too much overtime.
  4. Use management-speak.
  5. Try to be smarter than the geeks.
  6. Act inconsistently.
  7. Ignore the geeks.
  8. Make decisions without consulting them.
  9. Don’t give them tools.
  10. Forget that geeks are creative workers.

Read more

Nine things developers want more than money

  1. Being set up to succeed.
  2. Having excellent management.
  3. Learning new things.
  4. Exercising creativity and solving the right kind of problems.
  5. Having a voice.
  6. Being recognized for hard work.
  7. Building something that matters.
  8. Building software without an act of congress.
  9. Having few legacy constraints.

Read more

Top 10 ways to demotivate your programming team

  1. Set up impossible deadlines.
  2. Let them work overtime.
  3. Don’t allow breaks.
  4. Place a ban on laughing.
  5. Break the coffee machine.
  6. Don’t shield them from the dirty daily business.
  7. Don’t challenge them.
  8. Underpay them.
  9. Bribe them.
  10. Infiltrate a team member who is demotivated anyway.

Read more

Don’t bring me solutions, bring me problems

(Don’t tell me how you want it to work, tell me what you want it to do)

  1. Where all think alike, no one thinks very much.
  2. Suggesting solutions kills creativity.
  3. Don’t bring me solutions, bring me problems.

Read more

Classic mistakes enumerated

  1. Undermined motivation.
  2. Weak personnel.
  3. Uncontrolled problem employees.
  4. Heroics.
  5. Adding people to a late project.
  6. Noisy, crowded offices.
  7. Friction between developers and customers.
  8. Unrealistic expectations.
  9. Lack of effective project sponsorship.
  10. Lack of stakeholder buy-in.
  11. Lack of user input.
  12. Politics placed over substance.
  13. Wishful thinking.

Read more

Seven practices for healthier, faster software development

The practices discussed in this article are based on Ezequiel Cuellar’s observations. These practices will help any software development team as they come up against common obstacles. They will also contribute to a solid foundation for healthier development and help speed up production. The seven practices are:

  1. Improve business processes before starting development.
  2. Create a solid software development team.
  3. Improve processes for service requests.
  4. Minimize reporting of software metrics.
  5. Improve communication with the business team.
  6. Use the right programming language.
  7. Use the right IDE.

The practices target problems that are better addressed at the management level. Usually, developers can only report the issues to upper management for consideration. Because project managers have the necessary level of authorization, they are the ideal candidates to promote these practices within the organization.

Continue reading

Identifying Senior Software Engineers

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

Architecture-Oriented or Feature-Oriented?

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?

Foundations of Programming: Building Better Software

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)

Unit Testing: Rules of Thumb

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.

Version Control for Multiple Agile Teams

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.

Scrum and XP work well together

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!