VenkatSubramaniam

We constantly hear that change should be affordable and cost effective. True, but, in reality, that's easily said than done. Complexity makes change hard. We can't shy away from the hard problems posed by domains and business needs. So, how can we solve complicated problems without getting dragged into the quagmire of what appears to be an inevitable complexity? In this keynote, an award winning author and software practitioner will share experiences and observations from working on multiple software projects, about what leads to complexities, the traps developers and organizations fall into, and what we can do to effectively deal with these common, recurring issues we see across domains and products.

Creating code is easy, creating good code takes a lot of time, effort, discipline, and commitment. The code we create are truly the manifestations of our designs. Creating a lightweight design can help make the code more extensible and reusable.

Design patterns are common place in OO programming. With the introduction of lambda expressions in languages like Java, one has to wonder about their influence on design patterns.

Every developer takes pride in the code they write, as they should. But, we know not all code are created equal. Not all of us create good quality code all the time. So, putting aside personal biases, how can we measure the quality of code.

Before spending substantial effort in refactoring or altering design, it would be prudent to evaluate the current quality of design. This can help us decide if we should proceed with refactoring effort or a particular alteration of design. Furthermore, after evolving a design, using some design metrics would help us to evaluate if we have improved on the design front.

Before spending substantial effort in refactoring or altering design, it would be prudent to evaluate the current quality of design. This can help us decide if we should proceed with refactoring effort or a particular alteration of design. Furthermore, after evolving a design, using some design metrics would help us to evaluate if we have improved on the design front.

Reactive Programming is receiving quite a bit of attention and for good reasons. It’s a nice logic next step from functional programming. It takes the concept of function composition and lazy evaluations to the next level. It streamlines handling of many critical issues that are architectural in nature: resilience, scale, responsiveness, and messaging.

Reactive Programming is receiving quite a bit of attention and for good reasons. It’s a nice logic next step from functional programming. It takes the concept of function composition and lazy evaluations to the next level. It streamlines handling of many critical issues that are architectural in nature: resilience, scale, responsiveness, and messaging.

Using lambda expressions, programming with streams, making use of lazy evaluations, putting the functional pipeline to good use, all of those are well intended use of functional programming. Once we get past the syntax and the semantics, the real challenge emerges. How in the world to actually build systems to use this paradigm? Is it practical to build applications that honor immutability, how to structure the applications using higher-order functions, and how to deal with those gnarly exceptions?

Big data applications have entire different demands than typical CRUD applications that have ruled the enterprise for decades. When dealing with high frequency and high volume of data, we have to reach to a different set of tools than we have been used to.

Big up front design is discouraged in agile development. However, we know that architecture plays a significant part in software systems. Evolving architecture during the development of an application seems to be a risky business.

We all have seen our share of bad code and some really good code as well. What are some of the common anti patterns that seem to be recurring over and over in code that sucks? By learning about these code smells and avoiding them, we can greatly help make our code better.