Petabyte

Access ! Access ! For as long as I can remember writing programs in Java. I have used the access modifiers to control access to members of my classes. It is one of the topics in the Certification test in java (SCJP, OCJP). The table below taken from the Oracle Java Tutorials summarizes how each access modifier can restrict or expose a member of your class. Java Access Control Access Levels Modifier Class Package Subclass World public Y Y Y Y protected Y Y Y N no modifier Y Y N N private Y N N N Don't worry it is a private final variable! I can't change its value because it is private final member of the class. Well that is not really true. There is an API for that  Java Reflection . The Java Reflection API will allow you to examine and modify runtime behavior of applications in the JVM. "Reflection is powerful, but should not be used indiscriminately". In relation to the access modifiers mentioned above you can disregard it all and do as you please.

Big Ball of Mud (more likely Great Balls of Fire that will burn you down!) I am being mentored by Arun Batchu  this semester looking into the exciting world of software architecture and as a self study we should look into this  Big ball of Mud . I have read the page before and was also mentioned to me recently by my peer as we were discussing software architecture, Conway's Law , microservices architecture . The Big ball of mud page (1999) existed before the Agile Manifesto (2001) was conceived. This means that the observation that the authors wrote were noted before most of the agile processes ever existed but I somehow still observe the same kind of things (now more prevalent) in an agile world. Well I guess the forces that they have observed still applies to the software projects of the agile world. How would we consciously prevent ourselves from creating Big balls of mud ? I think that there is no clear answer to that because any software project will be constrained by

What stage is Agile Process of Software Development in its life?  The Agile Manifesto was created around 2001, so Agile development processes is now entering its teen years. During this year there is probably a lot of dilemma that software developers encounter with this method of software development. Like a teenager that succumb to peer pressure, Agile software methodologies becomes popular based on the most influential advocates of that process. But by now most software developers ,who tried most of the agile software methodologies, already know what works based on the successes it brought to our practice. Knowing what works means that we also know what doesn't work. Here is the dilemma, there is no one size fits all solution for agility because that is the whole point of agility. You need to react to factors of the current situation to best decide what is going to work.  If I understand Agile development, we start building before the outcome is fully understood. Adjust o