| Domain-Specific Languages: An Introductory Example
                                By
                                Martin FowlerSep 27, 2010In this excerpt from his book, Domain-Specific Languages, Martin Fowler offers a concrete example to demonstrate the different forms a DSL can take. 
 | 
|  Interview with Andrei Alexandrescu (Part 3 of 3)
                                By
                                Andrei Alexandrescu, Eric NieblerAug 25, 2010Eric Niebler and Andrei Alexandrescu conclude their conversation about the D programming language by discussing concurrency, the complications of sharing data, dynamic loading, specification and licensing, and the future of D.
 | 
| Interview with Andrei Alexandrescu (Part 2 of 3)
                                By
                                Andrei Alexandrescu, Eric NieblerAug 18, 2010Part 2 of this interview about the D programming language finds Eric Niebler and Andrei Alexandrescu deep in discussion about structs versus classes, the difficulties of copy semantics, rvalue references, the intricacies of garbage collection, and Andrei's occasional failure in serving as the standard-bearer for policy-based design.
 | 
| All Systems Are Go: An Interview with Rob Pike, the Co-developer of Google's Go Programming Language
                                By
                                Rob Pike, Danny KalevAug 17, 2010Danny Kalev talks with Rob Pike, the co-developer of Google's new Go programming language. In this interview, Pike speaks about the limitations of C++ in large-scale projects, the design philosophy of Go and its unusual type-system, and Go's future.
 | 
| Interview with Andrei Alexandrescu (Part 1 of 3)
                                By
                                Andrei Alexandrescu, Eric NieblerAug 11, 2010In part 1 of this three-part series, Eric Niebler talks with his pal and fellow InformIT contributor Andrei Alexandrescu about the D programming language and Andrei's new book about it: what makes D different from other languages, whether D's class libraries rival those of Java and .NET, and why Andrei claims not to be a guru.
 | 
| How to Build a Strong Virtual Team
                                By
                                Karen N. JohnsonMay 11, 2010Karen N. Johnson provides valuable advice for establishing and maintaining virtual relationships with team members. Using senses other than just your sight, paying attention to subtle clues, and putting in a little extra effort to be available when needed can help you to build a strong team that works together even when they're physically separated.
 | 
| Improve Your Testing and Your Testers with Paired Testing
                                By
                                Karen N. JohnsonApr 27, 2010Have you ever had testers on your team whose knowledge and skill sets were complementary, and wondered how you could encourage them to exchange and collaborate so that they could both increase their skills? Author Karen Johnson shows a different approach to testing and some of the advantages of pairing testers.
 | 
| The Design of Design: Exemplars in Design
                                By
                                Frederick P. BrooksApr 19, 2010Few designs are all-new. Usually, even novel designs derive from earlier artifacts intended for similar purposes and built with similar technology. What then is the proper role of exemplars, precedents, in design? How should the designer study and use them? Should each design domain develop an accessible cumulative store of exemplars? Frederick P. Brooks considers these questions in this excerpt from his book, The Design of Design.
 | 
| What Programmers Have to Know About Testing
                                By
                                Janet GregoryJan 11, 2010Janet Gregory offers some good advice to developers: Even when you know that a dedicated test team will be testing your software, there are some things that your programming team shouldn't leave for the testers to find.
 | 
| Robert C. Martin's Clean Code Tip #12: Eliminate Boolean Arguments
                                By
                                Robert C. MartinAug 25, 2009We join "The Craftsman," Robert C. Martin's series on an interstellar spacecraft where programmers hone their coding skills. In this twelfth tip in the series, the crew learns that Boolean arguments loudly declare that the function does more than one thing. They are confusing and should be eliminated.
 | 
| Helping the Development Team Learn More About the Business
                                By
                                Lisa CrispinAug 18, 2009Your software development team might be brilliant at testing and coding, but the team can support your business much better with software if they know that business inside and out. Lisa Crispin shows how the effort can pay off.
 | 
| Eight Terrifying Team Project Mistakes
                                By
                                John Paul MuellerAug 17, 2009John Paul Mueller shares project mistakes, including these frightening (true) examples. 
 | 
| Robert C. Martin's Clean Code Tip of the Week #8: Your Build Shouldn't Require More Than One Step
                                By
                                Robert C. MartinMay 16, 2009We join "The Craftsman," Robert C. Martin's series on an interstellar spacecraft where programmers hone their coding skills. In this eighth tip in the series, the crewmen learn that building a project should be a single trivial operation. 
 | 
| Robert C. Martin's Clean Code Tip of the Week #7: Clean up Old Commented Out Code
                                By
                                Robert C. MartinMar 30, 2009Robert C. Martin explains why old commented-out code is an abomination.  
 | 
| Robert C. Martin's Clean Code Tip of the Week #6: Avoid Poorly Written Comments
                                By
                                Robert C. MartinFeb 27, 2009We join "The Craftsman," Robert C. Martin's series on an interstellar spacecraft where programmers hone their coding skills. In this sixth tip in the series, the crewmen try to interpret a poorly worded comment. 
 | 
| Robert C. Martin's Clean Code Tip of the Week #4: Avoid Obsolete Comments
                                By
                                Robert C. MartinFeb 11, 2009A comment that has gotten old, irrelevant, and incorrect is obsolete. Obsolete comments tend to migrate away from the code they once described and become floating islands of irrelevance and misdirection. 
 | 
| Robert C. Martin's Clean Code Tip of the Week #3: Avoid Inappropriate Information
                                By
                                Robert C. MartinJan 28, 2009In this third tip of the series, programmers discuss how to avoid inappropriate information. 
 | 
| Robert C. Martin's Clean Code Tip of the Week #2: The Inverse Scope Law of Function Names
                                By
                                Robert C. MartinJan 21, 2009The longer the scope of a function, the shorter its name should be.
 | 
| Robert C. Martinโs Clean Code Tip of the Week #1: An Accidental Doppelgänger in Ruby
                                By
                                Robert C. MartinJan 7, 2009Robert C. Martin investigates an interesting dilemma: if the implementation of  two functions is identical, yet their intent is completely different, is it still duplicate code?
 | 
| What Is Clean Code?
                                By
                                Robert C. MartinAug 19, 2008Robert C. Martin introduces his book, Clean Code, and polls experienced programmers -- including Bjarne Stroustrup, Grady Booch, Dave Thomas, and Ward Cunningham -- on what their definition of  "Clean Code" is. 
 |