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.
I often hear this argument against immutable objects: "Yes, they are useful when the state doesn't change. However, in our case, we deal with frequently changing objects. We simply can't afford to create a new document every time we just need to change its title." Here is where I disagree: object title is not a state of a document, if you need to change it frequently. Instead, it is a document's behavior. A document can and must be immutable, if it is a good object, even when its title is changed frequently. Let me explain how.
When two or more software modules are accessing the same resource, they have to be synchronized. This means that only one module at a time should be working with the resource. Without such synchronization, there will be collisions and conflicts. This is especially true when we're talking about "resources" that do not support atomic transactions.
To solve this issue and prevent conflicts, we have to introduce one more element into the picture. All software modules, before accessing the resource, should capture a lock from a centralized server. Once the manipulations with the resource are complete, the module should release the lock. While the lock is being captured by one module, no other modules will be able to capture it. The approach is very simple and well-known. However, I didn't find any cloud services that would provide such a locking and unlocking service over a RESTful API. So I decided to create one—stateful.co.
TL;DR ORM is a terrible anti-pattern that violates all principles of object-oriented programming, tearing objects apart and turning them into dumb and passive data bags. There is no excuse for ORM existence in any application, be it a small web app or an enterprise-size system with thousands of tables and CRUD manipulations on them. What is the alternative? SQL-speaking objects.
A team working remotely requires much stronger discipline than a co-located crew sitting in the same office. First of all, I mean discipline of communications. At teamed.io, we have developed software remotely for the last five years. We manage tasks strictly through ticketing systems (like GitHub, JIRA, Trac, Basecamp, etc.) and discourage any informal communications, like Skype, HipChat, emails, or phone calls. Every ticket for us is an isolated task with its own life cycle, its own participants, and its own goal. Over these years, we've learned a few lessons that I want to share. If you also work remotely with your team, you may find them useful.