Friday, April 04, 2014

The Lost Art of Object-Oriented Analysis and Design

Yesterday, we concluded the first run of our fully-revised course on Object-Oriented Analysis and Design, with UML and GRASP Patterns. This was the product of two weeks of research and writing by O&B's VP, Lorenzo Dee. The target audience is business analysts, with minimal or no programming background, though we believe the material is also pretty useful as an introductory training course for new Computer Science grads, as a way to bridge their programming knowledge with the needs of the real world.

Besides writing from his and the company's collective experiences, he also referenced "Applying UML and Patterns" by Craig Larman, "Analysis Patterns" by Martin Fowler, "The Data Model Resource Book" by Len Silverston, and "Data Model Patterns" by David Hay, with Larman's book being the main reference.

Let me tell you how this course came about:  We felt that while Object-Oriented Programming was fairly discussed in school, and that while our developers received good training on Object-Oriented Design, we felt that the part in the middle - the Analysis, was missing. Throughout the industry, business analysts are often reduced to just documenters of requirements, and then they just hand over their documents to developers with very little input on design. Developers then take the requirements and then implement them however they wished, often with little regard to properly modeling the business domain that the system is supposed to automate.

Why does this matter? Initially, when codebases are small, it's not noticeable - the code that the developers write is not immediately traceable to the business domain, but that's ok because there's not much yet. When a business user talks about a bug or a change, the developers can still figure out where in the code the change has to be done because there's not much code to look through.

However, as the codebase grows to the size of any normal business system, the translation from business domain to implementation domain (the code), gets harder and harder and longer and longer. The developers have more code to read through, and it's not obvious which code implements which business operation. When a business users says something like, "there's a problem with the 'fund transfer' operation", or "we would like to change the 'seat booking process'", the developers have to read through thousands of lines of code figure out which parts of the code actually do that logic. So as a system grows, you will notice that bugs are taking longer and longer to fix, and new requirements are taking longer and longer to implement, to the point that the whole pace of change crawls to a near-standstill. Not to mention the cost of implementing changes skyrockets! And, it's so hard to bring onboard new developers to the team!

The solution here is to have developers build a rich "Domain Model" in their code, so that the code is a reflection of the real-world business domain. This means that the development team needs to have a strong analysis practice, as much as a strong programming practice. I'm not saying that these have to be separate people - many good developers are also good business analysts - but in order to make sure that developers maintain the discipline of implementing a rich, descriptive domain model (it's not easy to do), a dedicated, disciplined and well-trained business analyst is a good addition to the team; not just someone who can document requirements, but someone who can assert himself/herself in making sure that the business domain is properly modeled in the code.

With this in mind, the course that Lorenzo put together starts with breaking down of Use Cases into various UML representations. We also pointed to various references on established industry data models, so that the analysts would not be reinventing the wheel with each project. As much as half of a domain model can be adopted from existing, well-established data models. One of the best references here is  "The Data Model Resource Book" by Len Silverston.

A little caution here - we did not recommend creating full-blown class-diagrams and sequence diagrams right away. Rather, as Craig Larman recommends, we took them through various evolutions of modeling the business domain, with more and more detail with each evolution, and then only later on starting on the act of design, which meant for us the assignment of various behaviors to various parts of the system, using the GRASP patterns as a guide.

Emphasis was made to note that while we went through the full rigor of multiple steps from analysis to design, we needed to take this discipline within the context of Agile Software Development. As Larman would recommend, analysis and design are not big, upfront activities, but rather small activities of analysis and design are done throughout each iteration. Also, while the full rigor of the practice is discussed in the course, it is emphasized that with experience, the business analysts (and developers) will be able to do most of this rigor in their heads, and the time it takes to do analysis-to-design would be hours instead of days or months.

This first run opened up a lot of very insightful discussions with the attendees, most of which were seasoned business analysts, project managers and developers. Looking forward to more runs of this class and having more of these engaging and thought-provoking discussions!

Thursday, January 02, 2014

The Duty of Lucky Parents

Some nights ago, I walked past a homeless woman, sitting on the dirty sidewalk, gently holding her young boy in her arms. Both had a faraway look, like they were waiting – for nothing.

I couldn't bear to see the boy's look. I had just become a father 10 weeks back, and it seems every time see another young boy, I wonder what if my son would have been in his place. But even more unbearable for me was the look of the mother. I know that look, because I have had that faraway look myself, even during the first days when I held my own newborn son, similar to how she held her boy.

That faraway look was worry for my child. It would seem extremely silly to compare my worries to hers. My worries:  Would I be able to provide for my son the comforts and the education we aspire for him... Would I be able to provide him the time and wisdom to raise him to be a proper man... Would he be allergic to the pets...  Her worries, probably a lot more basic: maybe where she would find the next meal or two for her son, maybe basic medical care, and maybe distantly, a rudimentary education for her boy.

Hey, there's nothing wrong for parents to worry. Every parent knows that worry is just an inseparable part of parenthood. Regardless of our status in life, we worry – about our child's health, academics, career, social standing... However, for most of us who are parents able to read this blog post, we are almost assured that our children will eat three decent meals a day, receive a decent education, and proper health care. That doesn't stop us worrying – “How can I help him/her excel in academics?”, “Will we able to afford the best schools?”, “How do I help him/her choose and succeed in a career?” Worrying about our children is built into our DNA.

About two months ago, I watched on the news the heart-wrenching story of a father who stole the body of his two-year-old son from a hospital morgue, because he was worried that he wouldn't be able to pay the medical costs of the hospital and get his son out. He then waited all night outside of a charitable institution, hoping that in the morning the institution would give his son a proper burial. TV crews started to gather around him. He continued to tenderly embrace his son as any loving father would, occasionally planting a kiss, as tears fell continuously from his eyes. And then, that same faraway look of worry in his eyes. Even then, this parent continued to worry for his son, even if it was just to be able to provide for a decent burial. Fortunately a government agency learned about his story and committed to covering the cost of his sons burial.

I'm not trying to make us feel silly for worrying about our kids. It's just that when we worry, maybe we should also remind ourselves that we're the lucky parents. It's fine to aspire that your kid gets a scholarship to a top university, but we should also take comfort that even if he or she doesn't, your child will be blessed with a good education and plenty of opportunities in life.

But other than just counting our blessings, I think we lucky parents have some sort of a duty. How can we be of help to less-fortunate parents, and their children? Ok, I know we already have our hands full raising our own kids and juggling our careers at the same time, but maybe our very act of parenthood is a way to help others.

Beyond aspiring for our children career success, we of course want our children to be happy. Career achievements and money won't do that. Happiness comes from helping others. It will be the greatest blessing to our own children, if we raise them to be people who aspire to help others. And in the process of raising people who will help others, we will be blessing those less-fortunate children, and providing an answer to the worries of their parents.

So how do we raise our children to be people who help others? I'm certainly no parenting expert – heck I just started! However, I think we should strive to raise our children to posses three values – Compassion, Discipline, and Courage.

Compassion – It starts with the aspiration, of course. I would like my son to grow up with the desire to help others as the core motivation for his choices in life – what degree to take in college, what career to pursue, which organization to join (or start), or which direction he would lead others.

Discipline – My son will not be able to help others if he does not make himself capable to do so. He should know he has to work hard, acquire skills, and be dependable. He should also refuse to take dishonest shortcuts.

Courage – Change will always meet resistance. I hope that if my son sees that he needs to change a system that is keeping people at a disadvantage, that he is never discouraged by those that would stand in his way to maintain the status quo. I also hope that he will be willing to give up comfort or security, in pursuit of the changes he thinks need to be done.

Parenthood is certainly daunting – I am suddenly responsible for the happiness of another person, and I must guide him and provide for him for many years to come. The scale of human suffering in this world is daunting – I derive less enjoyment of the comforts I have in life when I know that so many people literally so near to me have serious, urgent problems that need to be addressed.

I feel blessed that in some small way, through my business and in other ways, I am able to be of help to others. I also feel blessed with the realization that if I can raise my son to be a person who helps others, I will be able to fulfill my goal of raising a person who is happy, and be of help to others at the same time.

Maybe if all of us who are lucky parents – who can provide our children with resources, time and guidance – aim to instill in our children compassion, discipline and courage, maybe we will raise enough leaders so that things start to change in the world. Perhaps with every succeeding generation, more and more people can count themselves as lucky parents, raising generations of leaders, solving the world's difficult and daunting problems, with each generation making the world a much better place.

Thursday, November 28, 2013

Consultants, You are Superheroes

Remember, my fellow consultants, that you are superheroes.  You have special powers, and you use those powers to help those in need.  Consulting is hard, because you're only needed when there are problems.  Your satisfaction is in solving problems and improving people's lives.

Superheroes don't go for applause.  In fact, we're often the scapegoats for the shortcomings of some people in our clients' organizations.  That's ok, even superheroes get blamed for crimes they didn't commit.  Superheroes remain noble, continuing to care about the best interests of their clients, continuing to save the day.

Every once in a while, when we do our jobs well, we get a "thank you" from a client - an acknowledgement that we have made their work and their lives a little better.  These moments make it all worth while.


Saturday, August 10, 2013

Top Three Missing Pieces with Startup Pitches I've Seen

I've advised a lot of groups with their startup pitches, and I often see the same things missing in their pitches.  Below is my usual advice to them:

Students of the UP-MIT Global Startup Lab
doing their first pitch.
1)  Cost the Problem

Pitchers often talk about a problem - not being able to find good reviews for restaurants, not knowing what the events are in your area, difficulty in finding parking - but not how much the problem costs or what people are willing to pay to make the problem go away.

The best pitches I hear go something like, "Mr. X loses Php 2 million pesos a year on his fish farm because he is unable to anticipate overheating of his fishponds.  Our device allows him to monitor the temperature of his fish farm and automatically turn on cooling mechanisms."

From statements like that, the investor knows that buyers are willing to pay some price between zero and two million pesos.  Multiply that by the number of Mr. Xs, and you have the potential size of the
market.

Remember that investors are interested not so much in solving problems but in how much money they can make, so start talking about money as early as possible.

2)  Who Are You?

It matters to investors who you are, because execution is more important than ideas.  What is your competitive unfair advantage?  If you are proposing a technology solution, are any of you engineers?  If you are tackling the problem of a particular market, is one of you an expert on that market?

First mover is not an advantage.  Any good idea will be copied by someone with more resources, so you will be in for a fight.  Give the investors a brief rundown on who you are and why you bring unfair advantages to the fight ahead.

3)  You Are Not Your Target Market

Unless you are, in which case see #2.   More often than not, you are building something for someone else.  "This is an app that addresses the needs of OFWs."  Are you an OFW, or are you close to any?  If not, don't make those assumptions.  Go out and validate your customers.

One of the best customer validation jobs I've seen on a Startup Weekend (where participants have to come up and defend startup plans and prototypes in just a weekend) was for some guy who wanted to build a parking app, and wanted to validate that people were willing to pay for parking spaces near mall entrances.  What he did was park near a mall entrance and approach passing drivers, offering them his parking slot for money.  He got one guy to pay him Php 40 and he moved out of his parking space for him.  So now he has validate his price of Php 40!  Remember, the best form of validation is revenue from real customers.

Well, that's my advice for you startupers out there.  I was starting to feel like a broken record so I decided to write all this down.  Hope the next group I advise reads this ahead so I can have a different conversation next time. :-)

Monday, July 08, 2013

The Role of the Filipino Engineer in Ending Poverty

Only two or three generations ago, Japan, Germany, South Korea, and Taiwan were in shambles, faced with the seemingly impossible task of recovering from war.  Now they are economic powerhouses, because their strength in engineering allowed them to design and build products desired by rest of the world.  


America's economic dominance was actually under threat by Japan and Germany in the '80s.  What saved them was the release by the US government of the Internet, which led to an explosion of innovation in information and communication technology, which reestablished America's economic dominance in the world.  

Speaking of information and communication technology, if you add up the top six companies in Silicon Valley their revenues are close to twice the GDP of the Philippines!  Each of those companies support thousands of other business, both high-tech and traditional.  All of those companies combined create thousands of jobs, and rich opportunities for entrepreneurs.

If California were an independent country, it would be the fifth largest economy!  And to think, these companies were formed just within this generation, mostly by young entrepreneurs with very little except talent and perseverance.  
Imagine if just a few Filipino engineers started technology businesses today, that would grow into global powerhouses tomorrow.  In just one generation, everything would change!  The amount of wealth double, and the distribution of this wealth would be more even, since the growth would come from entrepreneurs instead of the large conglomerates.  

Even our politics would change, if Silicon Valley is an indication of things to come.  Right now, the self-made entrepreneurs of Silicon Valley are banding together to lobby for such things as immigration reform, environmental policy and net neutrality.  The distribution of wealth from the few to the many will also lead to a distribution of power.  


One of the winning teams of Startup Weekend Cebu.
It's time for Filipino engineers to consider their potential role in Philippine society.  Instead of thinking of just advancing their careers, they should consider how they can maximize their potential to support the growth of this new economy, either by being entrepreneurs themselves or by supporting Filipino entrepreneurs.  

It's also time for our government, academe and financial institutions, to increase their support of technology entrepreneurs.  As all pioneers, their work will be tough, and many will fail.  We need to provide them with the knowledge and support systems to help them succeed, as well as support systems to help them pick themselves up and start over again when they fail. 
If Filipino engineers step-up to their potential,
they can change everything for the next generation.



Thursday, December 06, 2012

OOP Takes a While to Teach

I'm currently teaching a Java Boot Camp for developers coming from a non-OOP programming background.  We were moving quite fast on just the syntax portions, but we slowed down in OOP concepts like Inheritance and Polymorphism.  I realize I need to take two days on this instead of just one, and provide a lot of examples and coding exercises.

Saturday, November 17, 2012

Agile Outsourcing is Like Marriage - A 5-Step Agile Outsourcing How-To

There's a lot of horror stories in offshore outsourcing of software development, but every once in a while you hear of excellent partnerships. Sounds a lot like marriages, doesn't it?


There's actually parallels to marriage – You have to spend a lot of time in getting know a lot of potential partners until you find one. Then you're still not sure so you need to go through an extended period of “getting to know each other”. Finally, you make a commitment, but you need to invest a lot of time and energy to sustain and grow the relationship. And just like marriage, if it goes bad, it's just a big drain in energy, and you can't end it without feeling you've wasted so much time.


Step1: The Checklist

All single people have an initial list of “must-haves” for people they're willing to date. You should have the same in the search for an outsourcing partner.

Here's an initial checklist of things that the outsourcing firm should have, otherwise you should just cross them off your list:

  • Direct Video Contact to Individual Team Members

There's a dirty trick in outsourcing where you think you're emailing or chatting with a particular person, but the person behind that email address or chat ID may have already been replaced several times. Outsourcing companies that have problems with attrition try to hide this from their clients by pretending it's still the same person that the client is communicating to. In the age of free video conferencing, this danger is easily avoided. Of course, cross-off any firm that insists on a strict “single-point of contact” for all communication.

  • Training and Mentoring

The firm should have a training and mentoring program that reassures you that its people are consistently grounded on the practices that you are looking for. Don't hire a firm that just hires people and then lets them loose on your project without any training or mentoring, since such inconsistency in their practices can leave landmines in your code.

  • Sourcing of Talent

The company has to have some sort of competitive advantage in sourcing talent, otherwise it provides no advantage over others. Does it have any special relationships with universities or developer communities? Are the company leaders prominent personalities in the tech community?

  • Methodology

Almost all outsourcing companies say they're Agile now. Find out if they really know what they're talking about by speaking with someone. Don't talk to salespeople, talk to the operations people.

Step 2: Screening ("First Dates")

After short-listing some potential partners, it's important that you actually vet the individual developers who would be potentially assigned to your team. Before scheduling an interview, you can have them take a programming exam – after all, if they can't code, no point in wasting your time in an interview. We use the Codility online service for our programming exams.

If the developers pass the exam, set-up time to interview them, again ideally over video conference. It's fine to interview them all at the same time – it saves time and you also get an idea of the group dynamics. Group interviews also helps give confidence to those developers who are actually very good, but tend to get nervous during interviews. Ask the questions you would normally ask if you were hiring developers in-house.

Step 3: Starting the Relationship ("Going Steady")

Signing the first contract isn't marriage yet, it's just "going steady". It's important to start small, so that both sides have time to learn about each other and adjust. There's no set formulas for the group dynamics of geographically-separated teams, and each relationship will need to come up with their own ways of doing things as they go (I'm starting to feel like a relationship counselor here).

  • Small Team

Start with a team of just two or three people, for a project that will last around three months. Make sure at least one of the members of the team has a minimum of two years experience – you don't want to be hand holding an entire team of fresh grads, no matter how talented or trained.

  • High Interaction

Have as much interaction as possible during the start, ideally to the point of engaging in daily video scrums or even remote pair programming! There are already numerous articles and tools on remote pair programming, so I won't elaborate on it here, but please do search for them and check them out.

These daily interactions can seem stressful, especially if the remote team's timezone is not a match for yours, but this is just for the first few iterations. You can safely gradually reduce the intensity of the interactions towards the end of the “going steady” phase. Please remember the concept of “shared inconvenience” when dealing with timezones - if you can't find a common convenient time, take turns in sharing times that are inconvenient.

  • Engage the Management

Be sure to be engaged with the management of the company at this time. Meet with the company's management weekly to give feedback, so that they can perform the necessary interventions on their team, or give deserving performers a pat on the back. This is also an opportunity to request for specific resources that you are not happy with to be replaced.

Step 4: Committing ("Marriage")

Now that the “going steady” phase is over, the “marriage” phase can begin. This is typically where you negotiate longer contracts with a larger team size, in exchange for some flexibility with rates. As a side note, you can probably get more concessions from your partner if you agree to hire more junior developers onto your team, since these are usually easier for your partner to source.

You can scale down the intensity of the interactions during this phase, but as in marriage, you still need to put in effort to keep the relationship rich and growing.

  • Product Demos and Retrospectives

If daily scrums or remote pair programming is too intense, at a minimum, all core stakeholders from your side need to participate in Product Demos and Retrospectives at the end of each sprint. It's also advisable for the team to have retrospectives on their own so that they can speak freely among each other, but they need to share their feedback with the stakeholders on your end.

  • Visits
If schedule and budget permits, a great way to kick-off the “marriage” phase is a visit to your partner. There's no better way to build mutual trust and confidence than being face-to-face. This is a good time to conduct product training or domain training.

Some team-building activities between yourselves and your outsourced team would also be a good investment – anything from playing Laser-Tag or going to a beach resort together. You'd be surprised at how cheap recreational activities are in most outsourced destinations. This is also a good time for people on your side to unwind.

Also take the time to get to know the company's management. Schedule at least one lunch or dinner with them. Get to know their philosophy and vision for their company so you'll have a better idea on how to collaborate with them as your relationship progresses. You might even discover business synergies that you hadn't considered.

  • Allow Paid Time for Training

One of the top things that motivate talented people is opportunities to learn. You can help your outsourcing partner retain the people on your team, as well as make your team sharper, by allowing them to be trained on billable time. You can negotiate in your contract how many training hours per year, and what type of trainings will be billable, so it doesn't go too far.

  • Continue to Engage Management

The management of the firm are your partners in managing your team. Engage them early and often, not just when there's a problem. Share both positive and negative feedback. If there are problem team members, let them early so they can plan interventions – don't wait until you need to have him swapped out. If you have high performers, let the management know so he can be properly acknowledged.

Give the management advanced warning of team composition changes, either up or down. If you need to scale up, you need to give them time to recruit, train, or at least earmark certain people for transfer to your team. If you need to scale down or change people, don't give them a problem of what to do with people on the bench – give them an opportunity to plan where to reassign these people before you release them from your team.

Step 5: Allowing for Growth

The two people who enter into a marriage don't just stay the same people. They continue to grow as individuals, such as growth in their careers and career ambitions. This often puts a strain in a marriage, but as long as the core values of the couple remain intact, each person in the couple needs to adjust and support the growth of the other.

  • Promotions

I often encounter resistance from clients when we tell them that one or more of their well-performing team-members will be likely be promoted. They resent that it comes with an increase in billing rates. We tell them in advance, of course, so they can either make changes in budgets or decide to interview more junior people to take soon-to-be-promoted person's place, but it's still never taken well.

Keeping a well-performing person in a team without promoting him is a situation that can't last long. Eventually, the person will leave to find employment more deserving of his skill and professionalism. When that happens, both you and the outsourcing company lose.

Therefore, don't make it so hard for the outsourcing firm to promote its people. Even if your budget doesn't allow you to keep the person on your team, the person is still within the company, and can be called on by his colleagues in your team for advice.

  • Rotation

Even more difficult for clients to accept is the need for outsourcing and consulting firms to rotate their people between projects. As I mentioned earlier, talented people want learning and growth. If they can't get it in the company they're working for, they'll get it somewhere else, and then both client and provider lose.

The frequency of rotation is inverse to the seniority of the resource. Clients should expect movement of junior developers around once a year, mid-level developers around two years, and then senior developers around three years.

I hope you found this primer on Agile outsourcing helpful. If you have any questions, just drop me a line, and I'll be happy to answer.