Software outsourcing is what you go for when you want to create a software product but software engineering is not your core competence. It's a smart business practice being employed by everyone from $1,000 personal website owners to Fortune 100 monsters. And all of them fail, to some extent. Actually, it's very difficult not to fail. Here is my list of simple hints to everyone who decides to outsource software development (the most important ones are at the bottom). I wish someone would have given it to me 15 years ago.
Maintainability is the most valuable virtue of modern software development. Maintainability can basically be measured as the working time required for a new developer to learn the software before he or she can start making serious changes in it. The longer the time, the lower the maintainability. In some projects, this time requirement is close to infinity, which means it is literally unmaintainable. I believe there are seven fundamental and fatal sins that make our software unmaintainable. Here they are.
"Here is the specification; how much will it cost to create this software?" I hear this almost every day from clients of Teamed.io and prospects that are planning to become our clients and outsource the software development to us. My best answer is "I don't know; it depends." Sounds like a strange response for someone who claims he knows what he is doing, doesn't it? "Here is the 20-page specification that explains all the features of the product; how come you can't estimate the cost?" I can, but I won't. Here is why.
I suggest classifying class constructors in OOP as primary and secondary. A primary constructor is the one that constructs an object and encapsulates other objects inside it. A secondary one is simply a preparation step before calling a primary constructor and is not really a constructor but rather an introductory layer in front of a real constructing mechanism.
When I start to repeat myself in unit test methods by creating the same objects and preparing the data to run the test, I feel disappointed in my design. Long test methods with a lot of code duplication just don't look right. To simplify and shorten them, there are basically two options, at least in Java: 1) private properties initialized through @Before and @BeforeClass, and 2) private static methods. They both look anti-OOP to me, and I think there is an alternative. Let me explain.
Software outsourcing is a disaster waiting to happen; we all know that. First, you find a company that promises you everything you could wish for in a product—on-time and in-budget delivery, highest quality, beautiful user interface, cutting-edge technologies, and hassle-free lifetime support. So you send the first payment and your journey starts. The team hardly understands your needs, the quality is terrible, all your time and budget expectations are severely violated, and the level of frustration is skyrocketing. And the "best" part is that you can't get away or else all the money you've spent so far will go down the drain and you will have to start from scratch. You have to stay "married" to this team because you can't afford a "divorce." Is there a way to do software outsourcing right?
When you enter your email and password into the Facebook login page, you get into your account. Then, wherever you go in the site, you always see your photo at the top right corner of the page. Facebook remembers you and doesn't ask for the password again and again. This works thanks to HTTP cookies and is called cookie-based authentication. Even though this mechanism often causes some security problems, it is very popular and simple. Here is how Takes makes it possible in a few lines of code.
A software architect is a key person in any software project, no matter how big or small it is. An architect is personally responsible for the technical outcome of the entire team. A good architect knows what needs to be done and how it's going to be done, both architecturally and design-wise. In order to enforce this idea in practice, an architect uses two instruments: bugs and reviews.
A software architect is a key person in a software project, which I explained in my What Does a Software Architect Do? post a few months ago. The architect is personally responsible for the technical quality of the product we're developing. No matter how good the team is, how complex the technology is, how messy the requirements are, or how chaotic the project sponsor is, we blame the architect and no one else. Of course, we also reward the architect if we succeed. Here is what I, as project manager, expect from a good architect.