A tribute to Steve Jobs

I offer my tribute to Steve Jobs. A great man was he! I have never met him (although I so wished to have), I do not own any of his creations, but I truly respect the greatest enterpreneur of my field.

I have been hearing about Apple and Steve Jobs for almost a decade now. Somehow I had only associated him with Apple and innovations within it. Until I heard the commencement speech he gave at Stanford in 2005. One of the most inspiring speeches I've heard. That speech revealed a whole different side of Steve Jobs to me. It made him one of my role models.

What I took away from the speech?
- Stay hungry, Stay foolish
- Spend life doing things you truly love

May he rest in peace!

An introduction to Domain-Driven Design

This post tries to capture the need of Domain-Driven Design. It’s far from complete in terms of detailing all the best practices that can be applied in this field. The goal of the article is to introduce the reader to the terminology and the value of doing Domain-Driven Design and the dangers of not doing it. An example Domain-Driven approach to Legacy Modernization is used to cement the idea.

 

References: Domain-Driven Design Community

 

Software Complexity

The approach to design mainly determines how complex a piece of software can become. Software being too rigid to support changes or higher defect solving times often are indicators of high complexity. Software complexity can be broadly categorized into two types: Technological Complexity and Domain Complexity.

Technological Complexity

Technical constraints induce this type of complexity. Design considerations are made to tackle such constraints. A great amount of effort has gone into the design of networks, databases and other technological areas. By now many books have been written on these topics and developers have cultivated their skills to overcome these factors.

Domain Complexity

Domain complexity is induced by the domain where the software resides. A piece of software confused with domain terms, conditions and processes are often indicators of this form of complexity.

 

Why Domain-Driven Design?

Advances in the area of Technological Complexity have made it possible to reduce it's effect. Further, this complexity is often easily recognizable. For example, a design chosen to solve database locking can be documented as a technical design decision with reference implementation (which appears in the source code). Also, such complexity affects a particular layer in the software architecture, which makes it easier to tackle and maintain.
Domain Complexity, on the other hand, is a lot more complicated. Domain complexity generally affects all or most layers of the software architecture. If this complexity is not solved in the design, it wouldn't matter if all of the other technological complexities are dealt with. This domain complexity will, on its own, result into software which would not be maintainable and one which won't respond to changes. By incorporating the domain while designing software helps overcome this complexity. Domain-Driven Design tries to address this complexity.

 

What is Domain-Driven Design?

Domain-Driven Design, as the name suggests, is developing software keeping the business domain in the central position. It's not just about having a design in place before implementing the software. I assume that this is always the case. But the focus on the business domain is not so natural in the process of software development. Domain-Driven Design stresses on having a model for complex domain designs to lay focus on domain and domain logic. While designing such a model, the definition of ‘Bounded Context’ required careful attention.

Bounded Context

A model of a domain consists of abstractions and relationships between them. If you agree with the fact that there are always multiple models, you would also agree that there are multiple contexts. What is a context? A context is necessarily a boundary within which a particular abstraction or definition holds true. For example, a Loan in a Mortgages context is always coupled with an Insurance; which may not be true in another context. It's crucial to define this context and then begin defining abstractions within them. Key rules which hold true within such a context:

1. There is no duplication within a context. An abstraction conveys the same meaning throughout the whole context.
2. There is ONE unified model within a context.
3. Duplication is allowed between two contexts.

 

Example: A Domain-Driven Approach to Legacy Modernization

Most businesses feel the pain and therefore the need to get rid of legacy applications. Various approaches to Legacy Modernization are conceivable (at least in theory). I'll discuss couple of them:

Approach 1: Shutting down legacy

One of the approaches is to shutdown the existing legacy bits and kick off green-field development projects which would re-build the existing applications in a cool, modern architecture. An enthusiastic team then attempts to capture requirements of the new system. This is done either by extracting business logic from existing systems (called Harvesting) or talking to the business all over again. Either which ways, it's a tedious step. The second step of Forward Engineering typically consists of laying out the new architecture, getting infrastructure to support it and then employing developers and testers to implement the requirements.

Problems with this approach:

Chance of the same mistakes done again - This approach focuses on the core domain right at the end (a stage you may never end up in). The whole step of gathering/extracting requirements and setting up the infrastructure take away so much time that the project(s) is already delayed and one ends up with intensified development (sacrificing key principles, best practices) and hardly any testing. If one is lucky, this results in a new system which basically contains the same mistakes of the existing, legacy system, but now in a new language / platform. Building legacy all over again! I said lucky in the last sentence since this is really an extremely hopeful case which a project may not reach (it might be stopped much before that).

Questions to be asked:

• Why would someone (in this case The Business) want to build a new system exactly same as the existing one?
• What are the real pains with the existing ones? Maintainence time? Resistance to changes? Awkward connections? Are these pains really technological or due to lack of domain design?

Approach 2: A Domain-driven approach

Basic Principles:

• Treat legacy as Assets
• Focus on the core domain

Gradually phase-out the existing legacy systems and work on the core domain. Define the various contexts the existing systems cater to. Define unified models within that domain. Build an anti-corruption layer(s) which handles translation between the existing legacy systems and the core domain. These layers will be very very ugly but keep the core beautiful. Slowly move over to the services you wish the new system to provide. These reside on top of the core domain. Expand the system until all of the functionality catered to or expected from the legacy systems are covered.

Positives:

1. Due to a step-by-step take over approach, there will always be something live. This gets a business buy-in of the project.
2. The new system will not be a copy of the existing system; rather it would be the modern system which one hoped for.

Personalizing Privacy

A lot of buzz has been going around these days about websites not keeping your private information to themselves. I don't intend to go into 'whether this should be allowed or not' or 'what's right or not' in this blog.
I assume the above information is true, and that they are leaking your information. So what now?

OOP
When I was a student in OOP (Object Oriented Principles), I was introduced to the world of objects. An object is any entity that exists in your system context. An object has attributes (which determine it's state) and operations (which determine it's behavior). OOP also included important terms - 'encapsulation' and 'information hiding' which allowed these objects to be in full control. They were responsible to safeguarding their state. I'd like to treat each individual as an object and apply encapsulation and information hiding on him.

Private and Privacy?
Which information is considered private? While one considers information about his family 'private', the other says that it's his 'credit card' and 'bank-account' information, and a third his 'religious beliefs'. The content of what's considered private differs across cultures and individuals. Privacy is the ability to protect this information and reveal it selectively.

Designing the Private

Tricky and complex as it may sound, it's actually not that hard. Yes, it would not be possible to construct a generic, true-in-the-world-context model, but a simpler form is very much conceivable. Allow me to paint the following picture. Since each individual is his own judge to what's private to him, it's not difficult to build a simple object diagram with this information. Something along these lines..

This achieves two things - makes you think what's private to you and makes you aware what you'd like to share with these websites. I believe that self-awareness is already a victory achieved.





So the next time you come across a news article on a privacy leak, you know you have your list with you!

Journey to learning Dutch

It's taken me 2 years of evening  school, 2 times per week to pass the NT2-II exams. NT2 stands for 'Nederlands als Tweede Taal' (Dutch as the second language). More info on the exam here. The European Language Framework recognizes me at a Dutch level of B2 (refer Wikipedia).

Although Dutch is not really my second language, it has been real fun learning it. Until now, I knew languages - English, Hindi, Marathi, Konkani and Gujarati, and Dutch has been a very welcome addition. It's a very different experience trying to learn a language in your adult life. Being a software developer, I'm no stranger to learning new languages. But languages such as Java, Groovy, UML tend to have a strict set of rules which natural languages do not possess. With a natural language, it's often the rule, and then the exceptions to the rule. It's a bit hard to learn the exceptions, particularly when they're so varied. I often compare natural languages to the laws of society.

Initial Approach
My initial approach to learning Dutch was to learn the grammar. Naive! After few days of schooling and on advice from the teachers, I dropped that approach. I then focussed on learning more and more words and pronunciation. This helped me identify them being used in texts and communication. What sounded gibberish until then started to make some sense. I also made it a point to learn the correct spelling of the word while I memorized it.

Thinking in Dutch
There was this day after six or so months of schooling, when all of a sudden I stopped thinking in English. I could think in Dutch. This was the point of revelation. Learning after this point was so much easier. After this point, I focussed on the language grammar and tried to form sentences.

Speaking Dutch
Although I spoke Dutch in school, I did not have the confidence to speak it outside. I was motivated by my teachers to just start speaking in public without worrying about being completely correct. It was easier said than done. I hestitated because I could not express myself correctly. In an interview for a new assignment, I was asked to speak Dutch. They wished to check my Dutch since all of the system documentation was in Dutch. That was the first moment where I spoke Dutch outside school borders. It was like a hurdle passed, a big hurdle! (Felt like potential energy being transformed to kinetic energy). Although I thought I could have done much better if the interview were in English, I got the job. In this assignment, I began speaking and e-mailing in Dutch. The colleagues were supportive and understood that I was just a learner.

NT2 exams
I decided to give the NT2 exams on advice of one of my teachers. The diploma would be a proof of a certain level I have when it comes to the language. Although I cannot prove that my level of the English language is X, I decided to go for the NT2 exams. It served as a good challenge and at the same time a good end to the schooling journey. After a lot of preparation through sample exams, I appeared for the NT2 exams on 6 and 7 April 2011. The exams consist of four topics - writing, speaking, listening and reading. The listening exam still gives me the chills!

I'm very proud to have achieved this, something I had never thought I would need to do if you asked me 5 years back.

On the way to the abstract

Last week I started with a new assignment. My role is officially that of a SME (Subject Matter Expert). I am a part of the information analysis & design discipline in RUP (Rational Unified Process) terms. After being a part of the implementation discipline for a long time, this new role gives me an opportunity to walk my way to the abstract. I have always enjoyed the ‘meta’ level of things even in the development domain. This role opens a whole new meta world. I now have the control & the responsibility of coming up with solutions to business problems.

First goodbye mail

Already 7 years into my career and finally have the opportunity to write a Goodbye mail. At some level I always thought that they would be fun to write. After all, it’s not always or everyday that you get a chance to thank everyone you interacted or worked with.

Tomorrow’s my last working day at the current customer. I have been working with them for 11 months. I don’t wish to leave without writing them a goodbye mail.

I have put lot of thought in writing the mail. As it’s the first time I’m writing it, I do not have any templates which I can adhere to. Also I do not wish to copy someone else’s template. Plus I feel that such mails should be coming from one’s heart and are not to be written only to fulfill some norm/formality. I know I wouldn’t be writing one if it was just formality.

I feel the need to thank the people I have worked with. They have been a crucial part of my working environment the past year and I have learnt a lot from them. Now moving on to the next assignment taking everything what I learnt at the present customer.

Identity Crisis

So many applications, accounts, memberships! So many credentials (usernames and passwords) to remember! Sigh!

What do most of us do? Try to secure the same username for every account, have a list of favourite passwords and use them in succession. Try to maintain the account credentials either as a piece of paper with copies spread across to (secret) locations or as a little, local Excel sheet called ‘My Accounts’ or ‘My Passwords’. Some would complain about the security of such sheets and would rather save them under password protection or use a software which encrypts your accounts and stores it safely.

Here are some ideas which can make remembering passwords fun:
1. Memorize passwords as sentences - Like the sentence ‘The quick brown fox jumps over the lazy dog’ could yield a password ‘tqbfjotld’ formed by the first letter of each word. If you run out of sentences, use songs, poems. Now that is fun!
2. Passwords belong to a theme - You could build your passwords from certain themes. These themes could be anything from books, characters in movies, names of movies, art, etc. The more specific the theme gets, the harder it is to crack the passwords.
3. Build a robot which remembers your passwords for you - Not kidding here. I know someone who uses this option. Also fun!

Back to some basic questions: Why do you need an account or have to login into a software application? What happens on login?  The answer lies in two words: Identity and Access. Typically a software application comprises of certain functionality which is rendered to the end users. Access to this functionality is typically driven by the user’s role. The application therefore needs to identify the user, determine his/her role and grant access. For example, in a banking application, front-desk users might have access to submitting an account request, checking account status; while a back-office user could have access to creating accounts and a manager the access to generate & view reports. Although it’s the same application, different users based on their roles access it differently.

Can identity & access management be made simpler?
One cannot do away with accessing all those applications, but it certainly can be simplified. Here are some ways:
1. SSO (Single Sign On) - As the name suggests, all applications are weaved under a single sign on. An end user logs in once and is provided access to various applications falling under the SSO umbrella. This method is already implemented by organizations and is a handy way to expose local apps using this principle. Google has implemented for most of its internet apps. With one sign on and one Google account, you can access apps like Gtalk, Gmail, Gdocs, etc.
2. Biometrics - Biometrics consists of methods that uniquely identify human beings; with forms like retina recognition, finger prints recognition being the most popular. Who knows what technology brings in future, but at this current moment Biometrics is far from ideal of being used consistently, cheaply, worldwide by every software application; which makes option 1 the one to go for.

Outdoors @ Bartiméus

Bartiméus is an institution for the blind and the visually impaired. It houses around 350 people and aims to improve the quality of their life by providing personal advice, guidance and knowledge. It’s located in the midst of beautiful nature in Doorn, Netherlands. (Visit them at http://www.bartimeus.nl/)

 

On Friday 25 February, I got an opportunity to visit and help out at Bartiméus. It was arranged by the customer where I presently work. Bartiméus had an 'Ijskoud weekend' (Ice cold weekend) - a winter party on 26 and 27 February. We were to help out with decorating the place for the party.



The party consisted of several sections; the chapel, the school, the huts, party tents and the skating place. Our team was to help decorating all of these and help set up the party tents. After a briefing from the co-ordinator and a cup of tea, we were on our way.





I helped getting the decorations from the cellar and like a true developer contributed in one of the core services – inflating balloons. They need a lot of them and they needed them fast. The work-floor consisted of three balloon-inflating machines, lots of blue, white and silver balloons, lots of balloon string slipknots and four enthusiastic teammates (surprisingly fellow developers). Three of which kept themselves busy with the inflation of balloons and one of whom responsible to make bunches of five balloons. In a period of three hours, we inflated over six hundred balloons. Impressive eh! Our core services transformed Bartiméus into a party place ready to rock.

I truly enjoyed this outdoor activity. Still jump at every balloon burst though! Thanks Bartiméus.

That small square box!

Thanks to social networking sites like Twitter, Yammer, etc. that small square box has gained lot of importance. I’m talking about the box which holds your profile picture. It’s through this box that the world knows and recognizes you. Social networking allows us to interact with people we haven’t met before (in the traditional meeting sense that is). Whenever you try to remember information about someone, a picture is very essential. For example, you remembering your loved ones, parents is not possible without having a mental picture of that person. This is not just true for persons but also for events. You remember things and feel them through that mental picture. Memory is a collection of pictures. Even that mystery man or woman is remembered through a special mental picture you’ve formed.

Through social networking, we happen to know stuff about someone through their posts. But how do you remember that person? Yes, it’s through that magic, small, square box which generally forms the profile picture. This box is your mirror to the thousands or even millions whom you have influenced in one form or the other. Choose your profile picture wisely!

Our devices are getting wireless and we’re getting wired to them

The 21st century: where it wouldn’t be surprising to see a toddler playing with an iPad (although I still have to get one) or to find someone reporting a crime to the police over a webcam. From the advent of computing, there has been a continuous strive to bring the power of computing to the common man. These common men who used to hang out in café’s are now found hanging around on social networking or chatting sites. Common men who used to blindly trust newspapers, political leaders, religious preachers, teachers or even doctors for that matter now do so only after a background check on the internet. It wouldn’t be wrong to call this era ‘the information era’.

What is information? Are there positives or negatives to having access to it? Information for me is what you make of it. There’s no such thing as too much information. It depends on the recipient. Positives of having access to information are awareness, increase in knowledge, broader overview/mindset. What about negatives? I think lives were much simpler without this information burst. People could live in a cocoon created by the society and the number of people that affected or influenced ones lives was limited. In short, this information burst has literally caused that social cocoon to burst. But this burst has rendered the common man with the weapon which the elite few were thought to have.

Before this outburst, we were used to media like newspapers, television, radio, etc. But what makes information fun these days are the blogs, the tweets, the forums, the leaks; something which the other media couldn’t deliver : Interactivity. These create a sort of transparency which could only be imagined by our fore-fathers. Internet has become a medium which truly unites mankind.

The common man of this era is enslaved by information. He wants to have an access to information all the time. This is reflected in the devices that have sprung up lately. In the lights of smart phones, iPads, it’s now possible to access information all the time. The more wireless our devices are getting, the more wired we get to them. Whether good or bad, it's certainly here to stay!

Do we developers care about the business domain we work on?

Do we developers care about the business domain we’re working on? Or should we developers care about the business domain we’re working on? Domain knowledge for a developer is mostly a nice to have (and not a must have) entity. Sure, a developer with absolutely no knowledge about the domain can write good quality code incorporating all the patterns and best practices that are.  But can he/she produce a high-quality product? By product I mean here a ‘system’ or an ‘application’.

What happens when a developer tries to understand a business domain? Lot of knowledge transfer sessions take place between him/her and the functional guys/gals. Such a session typically includes lot of talk or lot of presentations flying around. After many of such meets, a developer begins to grasp the mechanics and dynamics of the domain. Super! He/She feels better equipped and motivated to do the task at hand. With that high-note, he/she begins reading the functional specs of the first use cases defined for the system. And most often to his/her utter disappointment, he/she realizes that not only are the specs ‘not complete’, but also wouldn’t fit together to make a 'complete system’. What happens then are more discussions where he/she tries to convince the functional specifiers of his/her findings. And before they all know it, the project is already running late resulting in enormous pressure on development to deliver working software. So was the whole need to understand the domain worth it!

The reason why this situation arises over and over again is due to the utterly bad tooling our functional specifiers use. Although these are the guys/gals who really understand and envision the system, they have no feedback on whether their specifications are complete and whether they end up in working software. More agile methodologies to software development have made this feedback cycle shorter, but it still exists. Wouldn’t it be nice for functional specifiers to have the tooling which validates their work? A tooling which guides them to a complete, working system. Some of you must have already guessed it. Yes, I’m talking about DSLs (Domain Specific Langauges) or DDD (Domain Driven Development) here. Languages which understand the domain and help specify it. This would remove that extra overhead and feedback loop.

Does this mean that the developers would be out of jobs? No, only now their time will be spent in developing these DSLs. This gives an opportunity to everyone to excel in their own discipline – the functional specifiers in the business domain and the developers in development. And also results in software which is tightly coupled to its specifications. A win-win-win I would say!

Motivation

When I started my career in IT back in 2004, I was a university graduate wanting to learn industry ways of developing software. The first years passed doing exactly this. Most of the methodologies learnt in the university were put to practice and I had a good feeling about this. Those were the times of ‘prime motivation’! Senior colleagues inspired me to work harder, gain knowledge and most of all have fun in developing software. My answer to college mates or fellow colleagues who would switch jobs for a higher salary was, “I’m learning a lot and enjoying what I do. I do not wish to change jobs”. Somehow these aspects always seemed more important to me and something which my fellow-mates did not always get.

Recently I read about the book ‘Motivation 3.0’ and saw one of the Ted talks on motivation. Both references prove that the ‘carrot and stick’ approach doesn’t help in getting job done faster; on the contrary this approach results in a bad performance. This approach results in people having a restricted line of thought. Projects like the Wikipedia are successful today since they bring out the best in people. People, by nature like to contribute, gain knowledge and attain mastery. Just having an environment which sees this and promotes this would suffice. Any other stimulants would not be needed. The best ideas in Google came about in the 20% free time that they have for their employees.

When I read about these, I said to myself, “Duh! I knew that. That’s common sense”. But then “Common sense isn’t that common”, one of the favourite quotes of one of my colleagues. The money-driven system is one of the root causes of the ‘lack of joy’ in one’s work today. We know that some of our needs come with a price, and often that price is our 40 hours in a week. One cannot put a price-tag on motivation. Motivation should be a continuous feeling and something which will take one through a long career. Motivation comes with the thirst to mastery, desire to do better and purpose. I know of an Indian film industry actor who refused receiving any film awards, but still is one of the most motivated fellows out there. Every movie he makes is a work of art. This world would be a different place if everyone steers or steered to making every piece of work they do a ‘work of art’!