Monday, October 24, 2005

So is code really model? And what is the mysterious word "code"

Sometimes, it seems so odd to call code a model. Why? Well, true it has the characteristics of a model, but I once thought, it is also more appropriate to say that code is at a higher level than machine code, but it is still "code".

Then the question arises what is "code" and it does it have to be textual? For the most part, yes. Once upon a time, code meant humans writing instructions that a machine can understand. There could be layers of transformers and compilers in between, but eventually it was for the machine to process and execute. And generally humans are more precise in wrting in text than drawing pictorial models, so computer scientists always resorted to a textual form for "code". Not that graphical models wouldn't work. I can imagine having machine level instructions generated from squares and circles and arrows between them. But as you can imagine this is not productive. Also, historically computer scientists were always very technical and had a math or physics mindset. And hence graphical models again never enticed them.

So, it always came to understanding in the computing industry that when someone says "code", alarms ring in the brain shouting, some textual representation understood by a computer by either consuming directly or by transforming it in layers in different intermediate languages. But even these intermediate languages are always perceived as to be textual.

So the next obvious question arises is "Whether all that is said above is true ? - Was it right to always perceive code as of some textual form".

Or whether code is nothing but a model representation of a programming language which eventually is a model of an intermediate language which in turn is a model of machine code? Are they all truly "models"? Just taking the avatar of textual representation? In theory, this statement seems right. But in practice, when the "how" comes into play, suddenly we are confused again. So is thinking in "how" really evil, and the textual form thinking, we have adopted "code" is a just a fallacy? Maybe, maybe not. Or maybe it is just one of the many buzzwords our industry is known to create. Or maybe "model" is just a word, that has a vague meaning in our industry.

Harry Pierson's this blog entry inspired me to write this entry. After reading it, for the most part, he convinced me to think of code in terms of model. And I also agree with the "tenets" he mentioned in his weblog. Also, I personally cannot imagine working on an enterprise level project without modeling the design and architecture level artifacts using some diagram like UML. And I also agree that models are of little value, if they are not used to transform and generate into code.

So yes, I think it is accurate to say, that code is model. It is theoretically sound and can be proved easily using Mathematical induction. Although I personally think that this distinction isn't as important as it seems. But I agree, it is good to get the vocabulary straightened out. So when someone speaks of a model, our brain tells us that he/she is just speaking of a high level abstraction to some low level abstraction, be it in text form or graphical or 3-dimensional - although that would be interesting - having each co-ords represent some special artifact :)

Before, I had always thought of UML diagrams as models, just because they were graphical. And there was a correction needed in my comprehension.

You can share your opinions in the comment section of Harry's weblog.

Wednesday, October 19, 2005

From Shrinkwrap to Custom Development

I was reading Joel Spolsky’s article - Set Your Priorities and found out that he has some interesting points on shrinkwrap software, consultingware and custom development.

But what is even more interesting is that, his writing is based on his own product, FogBugz, which is important to note, because the domain of the product is a general purpose one. The product does not encapsulate logic any of the logic of the business sector, the product will be used in, other than some configuration settings.

On the other hand, there are some products that specific to a particular domain and has assumptions of it made in the software. I have found that for products with these needs, consultingware and custom development is often more profitable than shrinkware, because you can give the customer that extra level of domain expertise, like a special web app for insurance companies.

Now, I am not saying the core architecture of the product is solely based on that model, but what I am trying to say is the core product architecture can be general level one, with all the common logic and abstractions modelled. But all the custom and special domain logic and functionality are designed to extend this model like plugins or modules and run on top of this.

This way you can have a very successful and fulfilling business model for software products that are intended for specific business domains.

Monday, October 17, 2005

Loose coupling between layers of an application

I was listening to Mario Cardinal's podcast discussion with George Hohpe, where they discuss the layering pattern and issues surrounding it.

Mario asks George, how can we loosen the coupling between layers, and George replies among other things, one can:

* Wrap lower layer exceptions in the upper layer's exception type and not expose them to the layer above. George thinks, this is almost always a good idea.
* Use the all mighty - Program to interfaces - even though the interface which is in the current layer, but has some or all of its implementations in the lower layer or even on layers at the same level, it is OK to depend on the interface. And use dependency injection to plug and play implementations at run-time, without actually being dependent on any one of them. This is also very useful for testing and mocking objects
* Use events - asynchronous or not (something I am adding) - so the upper layer can subscribe to some events of interest happening in the lower layers and can and get notified when they occur - aka Observer pattern - but applied to objects that could be potentially in different layers. Events are great to communicate messages and notifications without being coupled to the implementations that generate those events. The good part here is that the lower layer does not which objects in the layer above are listening to the events emittted.

Above all this, George says, no matter what, it takes only one bad coupling to break the entire loose coupling between layers, that's why this is sometimes so hard to get it right, especially in deployment scenarios.

You can listen to the podcast on Mario's website. This is his show # 7. He plans to do this oftenly and like his style of thinking and his questions are interesting. I plan to catch up with his podcasts, since I have used the Observer design pattern and asynchronously subsribed to his podcast notifications :)

Monday, October 10, 2005

Ruby is an interesting language

Ruby Programming Language: It's got iteration methods do: select, collect, inject:into from Smalltalk and many of the global variables from Perl.

Yet it mashes them in a nice piece that is easy to digest, and one that wants you come again for more.

It's interesting I am reading and learning more Smalltalk stuff, just because I am learning more about Ruby. Neverthought I would encounter Smalltalk docs, as I am relatively new - I started my computer science education in 2000.

I sometimes wondered what made Dave Thomas so zealous about Ruby. What did he saw in it, that he decided to dedicate months of his time mastering it. After reading his PickAxe book, and I now exactly why. What I found about Ruby is that, if you learn or study it with a positive attitude, reading to learn but not criticize or how it compares with your favorite language, it gets on you. It takes you over. You are like, what the heck - dynamic, closures, mixins, all the tasty globals, gems and libraries and the community - life is finally more fun.

But if you already took the time to learn, master, program in other oftenly compared languages like Python, you will appreciate some of its beauty and easily find some of its dents and issues. You are like, huh? Ok. Now, back to work. Although some of these guys are forcefully learning to learn the current phenomenon - RoR (ruby on rails), but what many of them don't get is - RoR's heart and soul is Ruby. It exploits its power and dynamic elegance and adds architectural patterns and framework models to it, giving it a nice rich personality. But Ruby is what inspired it. Without appreciating Ruby, learning and working with RoR is just like chasing the hype.

Ruby - It's the community, stupid!

Wednesday, October 05, 2005

An example where engineers came up with a solution to a problem when the language designers didn't

Constructors in modern OO programming languages have 2 main defects, that often cause annoyances, debates, discussions and often confusions

1. They handle the job of both constructing and initializing and besides they always have to create a new object, they can't return or initialize a previously allocated object

2. They can only return objects of their type and not of their subclasses

But software engineers and designers have happily come up with solutions that bypass these issues and now we are in a situation, that it would be OK if the next gen. OO language does not improve upon the current behavior. We are fine with it, we have found ways around and are now used to it, added in our code generators and our books.

This also proves that, the uses of a language is more powerful than the language itself.

Monday, October 03, 2005

When one pattern makes you think of others and reminds you of some refactorings!

When you use a Strategy pattern, you are now able to switch different implementations depending on the runtime environment or other domain logic.

But immediately you now have to worry - how to create the right strategy? Who will decide, who will create, where will the logic placed, what kind of configuration settings we will use, if any, or whether we will inject the strategy into the caller using dependency injection.

Hence, some of the following design patterns often come in mind, which when used along with the Strategy pattern makes a more complete solution:

Thinking of other patterns, in the light of a pattern is ofen lead by personal instincts, experience among other factors, but clearly having that ability seems extrememly valuable. These are different what GoF uses in their book, sort of related patterns. These are patterns that work in conjunction with the "base" pattern in question and are intended to serve as replacement of the base pattern.

Not only patterns, but it also makes you think of related refactorings that come in handy and preventing you from common pitfalls. Fowler and many others have made an impression of refactoring as applicable primarily to improve the design of "existing" code.

I, on the other hand them even in the design phase and often keep refactorings in the same toolbox as patterns, principles and practices. It makes me avoid making mistakes early on, that might need refactoring in the future. Hence, I think the term refactoring is sometimes, misleading. A more appropriate name would be just "Factoring".

Saturday, October 01, 2005

Search using the most common and popular resources on the net using rollyo

Using Rollyo, I created a personal search (Searchroll), that search common sites for software design patterns and architecture related resources.

Search Design Patterns Resources

Similarly I created a searchroll for the Ruby programming language and including sources from rails websites.

Search Ruby & Rails Resources

I have one created for Video Games too

Search Video Game Resources

Tuesday, September 13, 2005

Agile Design Checklist - The Fundamental Guidelines

The goal is have to arrive at a comprehensive yet generic list of good software design practices.

Category: OOAD

  • Modules that encapsulate high level policy should not depend upon
    modules that implement details. Rather, both kinds of modules should depend upon
    abstractions. See The Dependency Inversion Principle by Uncle Bob
  • Avoid "fat" interfaces - ones that are "non-cohesive". In other words, every interface is targeted to only a single client, not a group of clients. See The Interface Segregation Principle by Uncle Bob.
  • Remember the Law Of Demeter (also known as the Principle of Least Knowledge) - never call methods on objects you got from another method call nor call them on a global objects. Save yourself a lot of pain.
  • Schedule some time to design the exceptions in your system. Make concious decisions and make sure you think first about the clients who are the primary consumers. Exception design is the most ignored part of OOAD, partly because it does not correlate directly to any feature work or requirements.

Category: Design Patterns

  • Maintain a list of resources which makes it easy to find patterns that might be applicable to your domain. Here is a list of enterprise software patterns, Martin Fowler maintains. Some of them are books, and it is assumed you have access to them
  • Make sure not all patterns apply every time you see an opportunity. In other words, it is safe to say - Trust your instincts more than the patterns. This obviously assumes you have a good understanding of the patterns and experience with good software engineering and design practices over a period of time.

Category: Agile Practices

  • Don't foresee changes in your software requirements, architecture, design... Plan for change.

Category: Experience

  • Find a mentor who has passed the road of software salvation and have regular conversations with her/him. Share your experiences and laugh it our. See how much it works
  • Read blogs of people working in a similar domain of yours. Often bloggers post their experiences - learn from them. Learning from experiences is often better than from pedantry books. in progress...

Caveat: One thing that is true about life on earth is that, there are always exceptions. There will be situations that you might encounter in your design and development career, that sometimes it is best to keep the design simple and folllowing these principles simply adds more complexity and the value is not worth the effort.

Thursday, July 14, 2005

Software Design Patterns + Agile Practicies - The New Dictator - albeit a good one

Software Design and Architecture has been a prominent field of work since the late 70's. But only in the last decade or so have designers/developers (on a larger scale) realized some of its best practices.

Software design patterns pretty much dictate the quality of good software design. You know you are on the right track, when you have followed good design patterns and avoided anti-patterns. One can further say, that they pretty much dictate the design phase of projects.

Dictators are not likened by people in real life, but design patterns are here to stay and likened.

Put its good old friend - agile practices and you have a great team to work with. Finally follow some good principles like the good OOAD principles, Unce Bob maintains. Also, Martin Fowler's site is full of many goodies for the agile developer.

Wednesday, July 13, 2005

Agile Methods, Design Patterns, XP

In general, Agile methods strive to:

  • Eliminate Redundancy
  • Encourage Strong Cohesion (I like to say "very strong") for components
  • Encourage Loose Coupling (Again I like to say "very loose") between components

In general, Design Patterns strive to:

  • Design to interfaces
  • Favor aggregation over inheritance
  • Find what varies and encapsulating it
  • Shift the level of thinking to a higher perspective to encourage clear thoughts
  • Decide whether I have the right design, not just one that works
  • Think of objects as things with responsibilities

In general, XP (an agile methodology) strives for:

  • Simplicity (My favorite)
  • Effective Communication
  • Planning Game (Planning involves both discovering what the customer wants and estimating how long this will take to do)
  • Constant Feedback from every member involved in the project (Whole Team)
  • Involving customer as an integral part of the process (On-site customer)
  • Coding standards
  • Constant Refactoring of Code
  • Continuous Testing (Unit and Acceptance). Use of Test-Driven Development.
  • Continuous improvement of Design (See Refactoring to Patterns - by Joshua Kerievsky)
  • Continuous Integration
  • Small but often product releases
  • YAGNI (You Aren't Going to Need It)
  • Great Courage
  • More...

For more information on agile software development, see the Manifesto for Agile Software Development and the Agile Alliance. Also, a good quick read would be Fowler's The New Methodology article.

Design Patterns book by the GoF is the most authoritative reference on this topic, but might not be the best place to start. Design Patterns Explained : A New Perspective on Object-Oriented Design and Head First Design Patterns are better books to start with. This page maintained by Vince Huston has some good pointers to online resources related to the study and practice of Design Patterns.

XP in short, is a lightweight development process initially thought of by Kent Beck with his work with Ward Cunningham using the Smalltalk programming language. For more information on eXtreme Programming, refer to What is Extreme Programming?, Extreme Rules, What is Extreme Programming? and Extreme Programming (XP) FAQ. Extreme Programming Explained: Embrace Change is the seminal book on XP by Kent Beck. Test Driven Development (TDD) is one my favorite practice that XP encourages and I cannot imagine writing code without it. No other programmer has felt differently after giving it a fair shot.

© 2008 Vishal V. Shah. All rights reserved. Contents of this web site reflect my personal work and is not representative of my employer.