I have a new String(array,"UTF-8") in one place and exactly the same code in another place in my app. Actually, I may have it in many places. And every time, I have to use that "UTF-8" constant in order to create a String from a byte array. It would be very convenient to define it once somewhere and reuse it, just like Apache Commons is doing; see CharEncoding.UTF_8 (There are many other static literals there). These guys are setting a bad example! publicstatic "properties" are as bad as utility classes.
I don't even know where to start. Let's begin with this: If I don't understand you, it's your fault. This has to be the most basic, fundamental principle of a good software architect (well, of any engineer), but most of the architects I've met so far, in many companies, don't seem to believe in it. They don't understand that the job of a software architect is to make complex things simple, not the other way around. They use diagrams, which are the most popular instruments of an architect, to explain to us, programmers, what he or she has in mind. But the diagrams are usually very cryptic and hard to digest. What's worse is that the complexity goes up in line with their salaries—it's disgusting.
A year ago, I tried to explain how effectively data and its presentation can be separated in a web application with the help of XML and XSL. In a few words, instead of using templating (like JSP, Velocity, FreeMarker, etc.) and injection of data into HTML, we compose them in the form of an XML document and then let the XSL stylesheet transform them into HTML. Here is a brief example of how all this can be used together with the Takes framework.
A bug exists when something doesn't work as expected. A bug fix is basically a patch (a pull request) to the existing code base that is supposed to solve the problem and make sure that "something" works as expected. Very often, such a patch fixes one thing and breaks many others. I believe that sometimes it's necessary to reject a bug fix and ask its author to re-do the patch in order to protect the project from bigger problems. There are a few valid reasons for such a rejection, according to my experience.
Good programmers create fewer bugs while bad programmers cause more. Sounds logical, doesn't it? However, there is a lot of criticism of this way of thinking. Take this one, for example: Bugs are inevitable, and instead of expecting fewer bugs from us, let us focus on the right design and let testers find and report bugs; then we'll fix them. Or this one: Being afraid to make a mistake makes me write slower and experiment less, which translates into lower-quality software. Read more about that here and here. But allow me to look at this from a different perspective and assert that yes, indeed, good programmers create fewer bugs.
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.