Blog.CBojar.net

Many factors can force software to change, such as new business requirements or new technology requirements. As software developers, we have to handle the constant stream of new demands in a maintainable way. But sometimes we don't have the time, or we don't have the resources. We just need to make it work because they need it like yesterday! When we allow ourselves to get caught up in the frenzy, we let quality slip. Other times, we just didn't know. Or we had bad practices that we thought were fine. Quality slips all the same. Can we see these issues just by looking at the code? public List getPersons(String name, String firstName, int contacts, boolean sort, boolean dir) { ResultSet rs; List persons = new ArrayList (); if (name != null) { rs = db.query("SELECT * FROM People"); addAllPersons(rs, persons); if (sort) Collections.sort(persons); if (dir) return persons; } else { rs = db.query("SELECT * FROM People WHER

As programmers, we are always seeking to match great problems to elegant solutions. We want to solve a problem in a way that solves it forever. The larger the problem is, the greater our need to find that permanent solution. This thinking is what leads us to create hulking pieces of software that try to solve every problem but solve no problem well. These frameworks we create aim to be general enough to apply to an entire category, but lack the concrete details to be applicable to any specific need. We build these frameworks because building them is more interesting than the actual problem we have to solve. Who wants to write the software to track auto parts in a warehouse when we could write a framework that maps relational data to object workflows? We could use that framework on any problem like that. We just need to add tens of thousands more lines of code tightly coupled to our framework. Too bad all we end up writing is a giant framework and a giant business logic layer to... t