Can Refactoring Improve Design ?

Yes, it can but not always!

When can refactoring improve design? Refactoring can improve design when team members who do refactoring are not only just programmers who know only language constructs but also are designers who know design principles. Team members who perform refactoring need to be experienced programmers. That is not enough. They need to know design principles in order to improve design. Else, they will not be able to figure out if the structure and association of entities or classes need to be changed in order to improve the design of software systems. They will focus only on a single program or subset of classes while refactoring.

Refactoring cannot improve design when we put programmers through a crash course on refactoring. It is essential to train them on object oriented analysis and design. They need to learn all design principles as well as programming principles. If we take this approach, yes, refactoring can improve design.

There can be extreme cases of dealing with complex or legacy code. Refactoring of legacy code is a costly affair. This requires experienced designers who have the ability to discover the hidden design.

In his article ‘Discovering Hidden Design’, Michael Feathers has articulated this very well with an example. It is a good read for all software professionals.

Challenges in Distributed Agile

While executing multi-site projects, Agile practitioners do face several challenges due to factors such as distribution of teams that results in limitations in face-to-face communication, and cultural mix of teams that impedes team bonding.   In some instances  I have seen collocated Agile teams inducting distributed teams in order to implement distributed Agile.  In other instances, several virtual teams come together to implement distributed Agile.  In both cases, the short term results are not impressive because of the inherent challenges associated with distributed Agile. Also, several questions such as the following surface as challenges.

1) How do you ensure that everyone understands the project vision and builds adequate rapport to work as a team?
2) Are engineers making the right assumptions (and validating them) and understand their expectations?
3) Are team members aware of detrimental communication loops that can impact productivity?
4) How will team members involve in efficient query resolution and ensure that they preserve the tacit knowledge exchanges?
5) How do team members avoid the trap of 'Blame Game' that could arise from product demos at the master location?
6) How do team members own quality and improve both internal and external quality of the product?
7) How will senior leaders or program mangers react to unfinished user stories?
8) How accurate can be the status checks? How will Scrum Master(s) perform status checks?
9) When and Where will Root Cause Analysis happen? Who will participate?
10)  How will senior leaders maintain team motivation across virtual teams?

There are ways to manage distributed Agile challenges and ensure early success in projects.  Governance of distributed agile projects plays a crucial role in making this happen.   What has been your experience?  What are the critical success factors?

SQL - The Past, Present and Future

In June 1970 Dr. E. F. Codd published the seminal paper, "A Relational Model of Data for Large Shared Data Banks", in the Association of Computer Machinery (ACM) journal, Communications of the ACM. This paper laid the foundation of relational databases and Codd's model got accepted as the definitive model for relational database management systems (RDBMS) across research institutes in all continents.

For the past three decades SQL has been accepted as the standard RDBMS language. There are three key reasons for the longevity of SQL. They are a) Simplicity, b) Strong Mathematical Foundation and c) Adoption (by several vendors). The power of SQL increased tremendously over the past three decades and SQL emerged as the de-facto standard for relational databases.

The NoSQL movement of 1998 supports database implementations that are non-relational data stores of several categories such as document stores, graph databases, key-value stores, multi-valued databases, etc. There are several flavors of NoSQL implementations such as Oracle Corporation’s BerkeleyDB, Google’s BigTable, Apache’s Cassandra, and Amazon’s SimpleDB.

It is very evident that SQL and NoSQL movement are complementary. RDBMS and SQL implementations will continue to thrive in ecosystems that require OLTP support on relational data stores. What Next?