At teamed.io, we work in distributed teams and keep all our communications in tickets. Besides that, we encourage every developer on every project to report bugs whenever he or she finds them. We even pay for each bug found. Once in a while, I see bugs reported along these lines: "Can someone explain to me how to design this module?" or even "I haven't used this library before; please help me get started." My usual answer is, "This is not a school; nobody is going to teach you here!" I realize this sounds rather harsh to most developers who are just starting to work with us, so here I'll try to illustrate why such an attitude makes sense and is beneficial to both the programmers and the project.
Disclaimer: I'm talking about software projects here, which PMBOK defines as "temporary endeavors undertaken to create unique products, services, or results." If your team is engaged in continuous development or maintenance of software, this concept may not be relevant.
First, no matter what the methodology is, we all write software for our users (a.k.a. customers, project sponsors, end users, or clients). Second, no matter what the methodology is, we write incrementally, releasing features and bug fixes one by one. Maybe I'm saying something absolutely obvious here, but it's important to remember that each new version should first of all satisfy the needs of the user, not of us programmers. In other words, the way we decompose a big task into smaller pieces should be user-targeted, and that's why you always work top down. Let's see what I mean through a practical example.
Code reviews (a.k.a. peer reviews) must be a mandatory practice for every serious software development team. I hope there is no debate about this. Some do pre-merge code reviews, protecting their master/development branch from accidental mistakes. Others do post-merge regular reviews to discover bugs and inconsistencies after they are introduced by their authors. Some even do both, reviewing before merges and regularly after. Code reviews are very similar to a white-box testing technique where a tester looks for defects with full access to the sources of the software. In either case, a code review is a great instrument to increase quality and boost team motivation.
However, it's not so simple to do them right. I would even say it's very easy and comfortable to do them wrong. Most code reviews and reviewers I've seen make similar mistakes. That's why I decided to summarize the four basic principles of a good reviewer as I see them. Hopefully you find them helpful.
Maven is a build automation tool mostly for Java projects. It's a great tool, but it has one important drawback that has motivated the creation of similar tools, like Gradle and SBT. That weakness is its verbosity of configuration. Maven gets all project build parameters from pom.xml, an XML file that can get very long. I've seen POM files of 3,000-plus lines. Taking into account 1) recent DSL buzz and 2) fear of XML, it's only logical that many people don't like Maven because of its pom.xml verbosity.
But even if you're an XML fan who enjoys its strictness and elegance (like myself), you won't like the necessity to repeat yourself in pom.xml for every project. If you're working on multiple projects, code duplication will be enormous. An average Java web app uses a few dozen standard Maven plugins and almost the same number of pretty common dependencies, like JUnit, Apache Commons, Log4J, Mockito, etc. All of them have their versions and configurations, which have to be specified if you want to keep the project stable and avoid Maven warnings. Thus, once a new version of a plugin is released, you have to go through all pom.xml files in the projects you're working on and update it there. You obviously understand what code duplication means. It's a disaster. However, there is a solution.
XSL transformation (XSLT) is a powerful mechanism for converting one XML document into another. However, in Java, XML manipulations are rather verbose and complex. Even for a simple XSL transformation, you have to write a few dozen lines of code—and maybe even more than that if proper exception handling and logging is needed. jcabi-xml is a small open source library that makes life much easier by enabling XML parsing and XPath traversing with a few simple methods. Let's see how this library helps in XSL transformations.
We all have bosses. We also have customers who pay us for running their software projects. They are my bosses for the time of the contract. I'm also acting as a boss for developers who are working for teamed.io. It is obvious that a good employee/contractor is one who makes his boss/customer happy. But only a bad employee works toward this goal. Trying to make your boss happy is a false target that, if pursued, ruins the project. A professional employee works for the project, not for the boss.
You have a task assigned to you, and you don't like it. You are simply not in the mood. You don't know how to fix that damn bug. You have no idea how that bloody module was designed, and you don't know how it works. But you have to fix the issue, which was reported by someone who has no clue how this software works. You get frustrated and blame that stupid project manager and programmers who were fired two years ago. You spend hours just to find out how the code works. Then even more hours trying to fix it. In the end, you miss the deadline and everybody blames you. Been there, done that?
There is, however, an alternative approach that provides a professional exit from this situation. Here are some tips I recommend to my peers who code with me in teamed.io projects. In a nutshell, I'm going to explain how you can cut corners and remain professional, 1) protecting your nerves, 2) optimizing your project's expenses, and 3) increasing the quality of the source code.
Do you name variables like textLength, table_name, or current-user-email? All three are compound names that consist of more than one word. Even though they look more descriptive than name, length, or email, I would strongly recommend avoiding them. I believe a variable name that is more complex than a noun is a code smell. Why? Because we usually give a variable a compound name when its scope is so big and complex that a simple noun would sound ambiguous. And a big, complex scope is an obvious code smell.
The purpose of Continuous Integration is to tell us, the developers, when the product we're working on is not "packagable" any more. The sooner we get the signal, the better. Why? Because the damage will be younger if we find it sooner. The younger the damage, the easier it is to fix. There are many modern and high-quality hosted continuous integration services, but only one of them (to my knowledge) supports Windows as a build platform—appveyor.com. My experience tells me that it's a good practice to continuously integrate on different platforms at the same time, especially when developing an open source library. That's why, in teamed.io we're using AppVeyor in combination with Travis.