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.
A stand-up meeting (or simply "stand-up") is "a daily team-meeting held to provide a status update to the team members", according to Wikipedia. In the next few paragraphs, I attempt to explain why these meetings, despite being so popular in software development teams, are pure evil and should never be used by good managers.
I'm not saying they can be done right or wrong; there are plenty of articles about that. I'm not trying to give advice about how to do them properly so they work, either. I'm saying that a good manager should never have daily stand-ups. Because they not only "don't work" but also do very bad, sometimes catastrophic, things to your management process, whether it's agile or not. On the other hand, a bad manager will always use daily stand-ups as his or her key management instrument.
Most of our clients are rather surprised when we explain to them that they will have full access to the source code from the first day of the project. We let them see everything that is happening in the project, including the Git repository, bug reports, discussions between programmers, continuous integration fails, etc. They often tell me that other software development outsourcing teams keep this information in-house and deliver only final releases, rarely together with the source code.
I understand why other developers are trying to hide as much as possible. Giving a project sponsor full access to the development environment is not easy at all. Here is a summary of problems we've been having and our solutions. I hope they help you honestly show your clients all project internals and still keep them on board.
After a few recent posts about immutability, including "Objects Should Be Immutable" and "How an Immutable Object Can Have State and Behavior?", I was surprised by the number of comments saying that I badly misunderstood the idea. Most of those comments stated that an immutable object must always behave the same way—that is what immutability is about. What kind of immutability is it, if a method returns different results each time we call it? This is not how well-known immutable classes behave. Take, for example, String, BigInteger, Locale, URI, URL, Inet4Address, UUID, or wrapper classes for primitives, like Double and Integer. Other comments argued against the very definition of an immutable object as a representative of a mutable real-world entity. How could an immutable object represent a mutable entity? Huh?
I'm very surprised. This post is going to clarify the definition of an immutable object. First, here is a quick answer. How can an immutable object represent a mutable entity? Look at an immutable class, File, and its methods, for example length() and delete(). The class is immutable, according to Oracle documentation, and its methods may return different values each time we call them. An object of class File, being perfectly immutable, represents a mutable real-world entity, a file on disk.
Do you have a team of brilliant and enthusiastic programmers? Of course! You've carefully chosen them from a hundred candidates! Are they passionate about the product? Absolutely! They use cutting-edge technologies, never sleep, and hardly eat or drink anything except coffee! Do they believe in your business success? No doubts about it; they live and breathe all those features, releases, continuous delivery, user experience, etc. Are you sure they are developing the product correctly? Well, yes, you're pretty sure; why wouldn't they? ...
Does this sound familiar? I can't count how many times I've heard these stories told by startup founders. Most of them are in love with their teams ... until that day when it's time to hirea new one. There could be many possible reasons for such a fiasco, but one of them is a lack of regular, systematic, and independent technical reviews. Nothing demotivates a development team more than a lack of attention to their deliverables. On the other hand, a regular reconciliation of their results and your quality expectations is one of the key factors that will guarantee technical success for your startup. Below I summarize my experience with organizing such technical reviews.
Which line do you like more, the first or the second:
What is the difference? The first class HTTP encapsulates a URL, while the second one expects it as an argument of method read(). Technically, both objects do exactly the same thing: they read the content of the Google home page. Which one is the right design? Usually I hate to say this, but in this case I have to—it depends.