Deepak Karanth

Just note that the client side is still a monolith in this solution.

...continued....

There is a saying "As you sow, so shall you reap". We should also not forget to address some of a fundamental problems I have listed in the article. People learning to code should be given better material to learn from. I believe building great software, using clean code etc should be included right from the beginning, not as an after-thought or as an advanced course.

We also need to call only those as "programmers" or "engineers" who are able to produce quality artifacts and not just anyone who takes a "duct-tape" approach to building software. And believe me, only then will we see people truly interested in the craft of programming enter our industry as employees.

Whether you agree with the content of my article or not, I am glad my objective has been met - to get people think about care for our craft and code. Because at the end of the day, it is our care for the craft that will take the profession forward. Only when we ourselves care for what we do, will others (read managers, other non-coders) start respecting us for what we do.

Keep the comments coming in!

Thank you for all the great comments. Most of you have provided good suggestions on how we can salvage the situation and improve bad code. Many of you have mentioned about what causes bad code in the job - tight deadlines, management, lack of skills either from developer or others on the team etc. I agree they need to be addressed, each one of us should do our bit to solve them.

Jack, I am saying exactly what you have described. You missed an important word, I said "avoid" massive changes every sprint :-)

Architecture is the bridge between development teams and the business. A formal definition of an architecture stakeholder would go a long way in clarifying the expectations for the role.

Jenkins used to be good. But now a days, it is all about broken plugins, difficulty managing version depedencies, unexpected server shutdowns etc. For those of you who haven't tried TeamCity, give it a go. It is by far the easiest to configure and maintain.

No, not at all. Please read the "Caution" section. There is such a thing as "over drying". I generally find that DRY code almost follows the Single Responsibility Principle as well (or visa-versa). There are no rules that dictate how to write DRY code. You could use some static analysers to find the percentage of code that is duplicated. At the end of it all, the objective should be to have maintainable code.

Thank you. Yes, I agree and I will update the post on my personal site. I was wondering the same while writing the post, but then as long as it got the message across..

Yes, Shokunin. You are correct. I have updated the same on my personal site. DZone Editors, if you see this, please change SSD 100,000 to 1,000,000

John, I had a look at the links you provided. They look like amazing material for low level understanding of programming. However I think they are not for everyone as they are oriented towards research developers or low-level programming rather than a commercial developer working at a higher level of abstraction.

I wanted the list to be as diverse as possible. The Pragmatic Programmer and the books from Uncle Bob cover the same topics and more.