Archive for category Core Mindset
Public Wave Invites?
Posted by PEZ in Innovation, Values on November 12, 2009
I just experimented with an interesting thing on Google Wave. I made my “Invite others” wave public. Now anyone on Wave can invite people using my invites. Pretty cool. Just a minute after I made the wave public the first person entered and used two invites. It feels quite awesome. Can people handle it all the way? Will someone come in and just use up all the invites? We will soon know. =)
Has anyone else done this? Are there lots of public invite waves out there?
Flickr Searches in 3D
Posted by PEZ in Flex/AS, Innovation on November 3, 2009
I’m experimenting with tying that 3D Album I mentioned earlier to Flickr Searches. Looks like this for now
ThreeDeeGallery.swf
Work in progress, both the app and this blog post.
Innovation – the heartbeat of products
Posted by Ram Sundararajan in Social, Values on July 31, 2009
Lately, I have been thinking and reading articles about innovation and innovative companies and I finally got the time to jot it all down over the weekend. And here are my thoughts…
Many companies want to be perceived as innovative. But are they really innovative?
Part of any process in a company should be to focus on products, the end goal that forms, guides and informs innovation. Wanton innovation is wasteful. There must be something in the product to pull it all together.
There are many companies that develop new technologies and go in search of problems for those technologies to solve. Take the internet bubble for instance; it was defined by this kind of thinking. It was a carnival of worthless innovation. Half baked business ideas and models pumped into money burning concerns in a misguided attempt to make quick bucks and beat the competition. Entrepreneurs launched websites for selling pet foods and some built gaint warehouses for delivering groceries by van. It turned out that no one wanted to buy groceries delivered to them by web van’s warehouses. Alas! The internet bubble burst taking with it all these half baked “innovative” ideas and businesses that had developed solutions to problems that never existed.
We need a very product oriented culture in companies. Lots of them have tons of great engineers and talented smart people. But ultimately there needs to be some gravitational force in the product to pull it all together. This gravity is what I feel innovation is all about.
I strongly believe that money is not the key for innovation. The key is the product focus and a product development cycle that has room for innovation. Microsoft for instance, spends billions of dollars in Research. Every year it invites journalists to look at its massive concrete and glass structure full of “innovations”. Yet, they end up copying things that Google or Apple does. Look at hotmail or yahoo mail apps. Its gmail mocked! Or Zune, the Microsoft variant of iPod, an obvious copy. The only product I know, correct me if I am wrong, that came out of these research facilities is the speech recognition component in Vista. Yeah it works well, but it is not a killer like gmail or iPod.
Talking about the key aspects of innovation, I think the company’s focus on the product is a must. If a company wants to be innovative and wants to differentiate itself from the rest, I think that it should question its products and its product development cycle.
As an example, let us look at Kano model of customer satisfaction.
It categorizes the features built into any new product as
• Must have feaures
• Linear features
• Exciter features
Must have features are the ones that must be in the product to be useful. Without the must haves there is no product. However, I feel that the must have features need not be fully implemented when the product is released. A “just about right” or “lagom” amount of completed must haves will do.
Research suggests, that although without the must have features the product will be useless, it is the linears and the exciters that gives more satisfied users.
Let us say, that I wanted to build a hand held music player. What are the must haves required for this tool to be useful?
Let us assume, a good head set, some hard drive to store music files, a play/pause/rewind/fast forward button
One can of course spend a lot of time for instance to make the head set really really good. But a good enough head set would fetch us “just about satisfied” users. There are other important things that can make the player really good. So lets stop there and move on!
The Linears, they are the ones that gives the user more satisfaction. A linear feature is the one for which “the more the merrier” holds true. It is called linear because customer satisfaction grows linearly with the quantity of these kinds of features. The more the linears in the music player the more satisfied the user gets.
Some examples of the linears I would like to add to the music player are
1. Good battery
2. A good display
3. A scroll wheel on the sides to browse music
4. Auto and manual lock/unlock button to lock when the user is on the move
5. Slick design
6. Light weight
7. Games, calendar, clock etc
Exciters are the ones that add great satisfaction to the customer. It often adds a price premium to the product. However, a lack of exciters will not decrease the customer satisfaction below neutral. But I believe that exciters are the ones that will make the product be perceived as innovative and these are the ones that make the product stand out from the rest of the pack.
Some exciters for the music player would be
1. As soon as I plugin the music player, it will bring up the users’ default music player (whatever it might be) and sync songs both ways.
2. Charge free device that uses solar and advanced light sensitive batteries
3. Maximum of 2 clicks to access any song on the hard drive.
4. No buttons in the player. We make the whole music player a touch screen.
In whatever feature in a product we do, we got to have 1 or 2 real exciters. Look at gmail for instance; they have built in at least one exciter in any type of functionality you find there…that is innovation! Google’s key to beat the competitive market where yahoo mail and hotmail once ruled!
For a product to be innovative, companies should integrate both linears and exciters in their feature list and make it transparent in their product development cycle. Categorizing features this way can contribute to an innovative company.
I believe that only innovative companies can stand in this harsh, competitive, volatile market. The more successful a company is in finding and implementing the exciters, the longer and happier the customer stays and hence stronger and faster the company grows. Many companies focus on adding a lot of linears to their application, this is not bad afterall. But they have to realize that time is wasted! Linear features increase the customer satisfaction to only a certain degree. They will not fetch greatly satisfied customers. Feature freaks got to think about it and control their temptation!
“Do you need satisfied or greatly satisfied customers?” One real good exciter is better than 10 different features. To me, it is like comparing a man to monkey!
So, let us all build more exciters…not just features!
Points or days? Should we care?!
Posted by Ram Sundararajan in Social, Values on July 27, 2009
Some months back, I wrote a mail to you guys about the easiness and the usefulness of using points system in a story instead of calculating its size in days or hours. I thought that I should blog this discussion now as I think that it might be useful for others too.
For calculating the effort involved in a story we now use days as the unit. By days we actually mean “ideal” days.
That is, we smartly ignore other work related things a developer does in a typical day and calculate only the amount of time s/he has to spend on the story.
We have calculated an ideal day to be 60 % of the developers’ typical day. In other words, it is 4.8 hrs or let us say 5 hours to approximate.
I think that this ideal day system for measuring the effort or size of a story brings in some unnecessary ambiguity into our calculations.
To understand what I mean, let us go back and ponder on what estimation means to us?
What are we trying to do in the estimating meetings?
The answer I think is, during the estimation meetings we are trying to define the size of each user story. In other words, we are trying to categorize each user story based on our previous experience and calculate the effort involved to put these stories into sizes or points like S, XS, M, L and XL or 1,2,3,5, and 8 respectively.
Great, so why do you use “ideal” days?
Well, I think that we use ideal days because we somehow wanted to relate time to effort so that we can know how many actual days a story is going to take or taken. Also, it becomes easy to express the status in number of days to the stakeholders rather than with an abstract entity called points. Yepp, true…but I think, this creates ambiguity to a very large extent when practised. For instance, an ideal day for person A need not be the same as the ideal day for Person B. So I think this system is highly subjective. It does not make sense to me to use a system that varies a lot between individuals.
If we wanted to measure how long a story is going to take, we should instead use the team velocity and perhaps create baselines using Burn down charts.
These two measures together can give a better approximate estimate in time for a story.
Let me add some weight to my argument with Mike Cohn’s thoughts on estimation
Choosing between story points and ideal days
With Agile methods, it is perfectly okay to use either points or ideal days as the measure of the size of a user story.
But I think that the points system is more advantageous and complete. Read on…to know why?
According to Mike (and I totally agree with him of course), below are the key advantages of using a points system
a) My ideal days are not your ideal days
b) Points estimate do not decay
c) Points are pure measures of size
d) Points estimation are usually clearer and thus faster
a) My ideal days are not your ideal days
Let us say, two runners one fast and one slow are standing at the start of a trial. Each can see the whole track of the trial and can easily agree that the track is one kilometre long. They either come to the agreement because of their previous experience or by comparing it with another track. Either way the process is easy and intuitive. Tracking the length of the trial is similar to the points system. That is, one simply measures the size.
Now, let us bring in some ambiguity by adding more parameters…
Suppose instead of discussing the length of the track, the runners wanted to calculate the time it takes to run the trial. Obviously, the time taken by the fast runner will always be lesser than the slower one. It is going to be difficult for these runners now to come to a consensus. Both of them with different numbers are correct from their point of view. They probably will never agree as to how long it will take to run the trial.
There is another thing that we need to pay attention too. An Ideal day between developers differ a lot because they are constantly involved with something else other than the story development. Things like support issues, big maintenance bug fixes, investigation, design for future projects all takes time.
So as said, the ideal days system is too subjective to be a standard.
b) Points estimate do not decay
An estimate in points has a longer life span than estimates in ideal days. It is simply because the point estimate only takes into account one parameter and that is the size.
Let me explain this with an example. Let’s say that we are to use ideal days to estimate a story that has to use a new technology like flex. We know that none of the developers have worked with it before and we have to do a lot of investigation and learning to produce the story feature. So, let us assume that the developer estimates it will take 13 ideal days to complete the story. Great!
Now, let us fast forward a few sprints and ask the same developer how long another similar flex story will take to do. Obviously, the estimate will be lesser, let’s say s/he says 3 ideal days. Bingo! we got a problem here. Similar stories take different amount of days to implement.
Many teams tend to ignore this as a problem because they think it is only logical that the amount of ideal days decreased, because the developer knows more about the technology now than before. They also argue that measuring team velocity over time would even out this difference. But it actually won’t in reality.
Because…we will see that using ideal days, the team velocity always remains the same even though developers do more work. See, the developer now after a few sprints produces the same feature in 3 ideal days, where the first time it took 13 ideal days. In other words, in 13 days the developer is now capable of producing 4 such stories (4 stories X 3 ideal days = 12 ideal days). But with ideal days the developer’s velocity is always 13 even though s/he can complete 4 such 13 days stories in 13 days. So ideal days do not reflect the actual team velocity in this case. (logically, after a few months the team velocity should have gone up)
With the points system, we do not take time into account…we just calculate the size. For instance, we say that the flex story is about 8 points or XL large and then after a few months, the team velocity is calculated, now we see that the velocity goes up because the team is now able to complete X number of more XL stories than they did previously.
c) Points are pure measures of size
As said earlier, points are pure measures of size and ideal days are not. Of course, ideal days can be used as a measure of size, but with deficiencies. As in the above example, points remain the same but ideal days tend to vary depending on the developers expertise.
Story points being pure measure of size has a couple of advantages. First of all, story points allow the team to estimate stories with analogies. It makes the estimation easy and more fun as we are only talking about “this story is like the other one” and hence should be for example an L or 5 points. When we estimate in ideal days, we can use the same analogy approach, but the problem is that we tend to bring in the calendar days and measure how long a story will take to execute instead of looking at how big a story is. As said, “how long” approach has hidden problems!
Secondly, a story being an abstract measure of size escapes the temptation to correlate it with reality or time. Less is more!
Ideal days has an inherent comparison built in :-) That is, we tend to always end up comparing actual vs ideal time.
Then this pondering eventually ends up with questions like, “how the heck we ‘only’ did 8 ideal days of work in a 14 day iteration?” You know more often than not, many teams put the blame on some bully. :-)
d) Points estimation are usually clearer and thus faster
Yes, to me it sounds obvious that it should be really easy to estimate a story on just the size. We skip detailed level of discussion and it makes things easy.
So in estimation meetings, we got to decide only if a story is an XL or M?…Then arises suggestions like we got to do these and these things. Further the last time we worked on that piece of code we found that we had to re-factor it etc. We can also use our previous stories as analogies. Perhaps a similar story that was an XL involves lesser effort this time?! Maybe maybe not…that’s what we decide in estimation meetings.
My point here is that it is easy to talk on higher level and skip going into the details.
Of course, we got to break down the story into smaller tasks. But that has nothing to do with estimating a story size.
Finally, I think that estimation in ideal days has some advantages. But I unfortunately can see only one obvious thing.
Stakeholders want to know when a story will be finished. Is it by Aug 1 or Aug 15? Calculating ideal days might be easier
to get to the date the stakeholder wants to know. But it is like a shortcut and it creates a lot of side effects for the team members.
So I think we gotta stick to the best practises that agile gurus suggest. That is points for a story size and velocity based on points for the team! Just as Ez as it can be :-)
Bad business shouldn’t be in business
Lots of (most) people think we live in a market economy. I beg to differ. Plan economy better describes it. If it was a market economy, how come the market doesn’t set the interest rate? And how come, when the financial systems melt down because of sub optimizing in the sea of regulations, the answer is always more regulations? If Obama and his followers around the world gets it their way financial business, and even business that goes “To Big To Fail” (an arbitrary label put on any business that the governments can’t keep their fingers off of), will have to carry even larger legions of bureaucrats and politicians on their back in order to have permission to operate. The result will of course be even more volatility for the markets and higher prices paired with lower quality of service for us citizens. But do the Obamas of the world care? No, what they care about is taking this wonderful opportunity to meddle with peoples affairs, just like they did when those terrorists managed to kill so many innocents back in September 11 2001, just like they always do at the time of any crisis.
The problem is a bit like a super Kinder Egg. Four (unpleasant) presents in one package; Bailouts, Fake interest rates, government regulations and “Stimulus”. Unlike real presents though, we are paying for them ourselves. This blog post addresses the Bailouts. If I find some more time to write I’ll deal with the other Kinder Egg content in coming posts.
Bailouts
If this is a market economy why is it that banks and insurers that suck at doing business are propped up and bailed out by the governments? In the U.S. the bailout costs so far are approaching $10 trillion. Now, that’s a lot of money!. Check this article out to get an idea on how fast these bailout trillions are burning. In a market economy failing businesses fail and resources are reallocated to good business. Jim Rogers, chairman of Singapore-based Rogers Holdings has understood this and says:
The U.S. is taking assets from competent people and giving them to incompetent people. That’s bad economics.
(From Bloomberg article U.S. Bailouts Add to Risk of Depression.)
Contrast that with what the mainstream opinion holds true:
Banks that fail hurt the society.
(Freely translated from this editorial in Sweden’s largest news paper.)
In our phony economy banks don’t need to care about the long term. In the booms bank managements can reap as much as possible from the speed-blindness of the market, stuff their own pockets full with those insane bonuses and pretend it is a reward for business success. In the busts their business will stand completely unprepared, naked and vulnerable, but these nigh-criminals can just shrug their shoulders and rest assured that our tax money will step in and save their asses.
What this system does is to perpetuate the bad leadership in these institutions. It’s not setup for learning anything good. And, as you may or may not know, I’m crazy about learning. In a market economy the business these lousy managers run would fail. These people would have big ugly FAILs in their CV:s and they would have to find jobs better suited for them (something involving minimum responsibilities of any kind). As it is now they can continue their careers like if they actually knew what they are doing.
There’s also no incentive for these businesses to start competing using arguments like “with us your money is safer than with them”. Remember, in our messed up economy, money we put in the bank is just as safe regardless of what bank we choose. The governments think they own our tax money. They will use it to prop these banks and insurers up and even bail them out if it comes to that. Then they will act surprised and exasperated when the bank managers try to use the tax money to enrich themselves even more. In reality we have these criminals as bank managers because we deserve it.
Some say we should nationalize these bad banks. Like they would be run better by politicians. Like that wouldn’t be an even surer way to burn up our tax money. In Sweden, Bailout nation #1, politicians are trained to find some middle ground. What they try to do is to give the tax money to the banks if the banks sign a contract about how the money can be used. For some reason politicians seem to think of themselves as good business people. They don’t see that all they are doing is playing Monopoly with our tax money. (Or maybe they see that and laugh at the joke.) The really sad part of this story is that lots of the Obamas in the world are impressed with what’s called The Swedish Bailout Model. Sweden is successfully exporting it! The world must of course move in the opposite direction. Away from plan economy and towards market economy.
A little bit of Apple today…
Posted by Ram Sundararajan in Innovation, Values on July 7, 2009
Last night, I was reading a book by Leander Kahney. It is called “Inside Steve’s Brain”. I was mostly inspired to buy the book because of Google Story, the other book that I read some weeks back. Though both the books cannot be compared, to be honest I think this book lacks the flow. The author just wanders all around. Seems like it is just a collection of all news articles over a decade collected into one book with absolutely no concurrency. I was kind of cheated by the title in plain words. I was expecting the author to have had at least some kind of personal talk with Steve Jobs…at least a jovial walk with Steve on the streets of Palo Alto. Anyway, this blog is not intended to be a critic of the book. I think there are some good take-aways in there. Below is one of them…
Though not very surprising, it was interesting to read how much time Apple spends on the design of each and every little component from hardware to software to packaging. I was amazed to read that Steve and his bunch of talented designers were designing just the scrollbar function of Mac OS X for many weeks.No wonder why Microsoft’s scrollbars sucks when you compare it with OS X. For Apple “no detail is too small”.
Steve on the Mac OS X release said “We made the buttons on the screen look so good you’ll want to lick them”. Very true indeed! :-)
One thing that intrigues me is how much detail oriented Apple as a company really is. I think the way their designers apply common world solutions for solving technical design problems, is what makes their GUI more intuitive. I think this is one aspect that distinguishes Apple’s user friendliness from others.
Here is a little story from Apple …
At one design meeting Apple guys were scrutinizing the three little buttons on the top left corner of every window. These were used for closing, shrinking and expanding. The designers had made all the buttons the same muted gray, to prevent them from distracting the user. But it was difficult to tell what they were for. Hard to communicate what these buttons did before the user clicks on it. There were many interesting suggestions to the problem and Jobs came up with what seemed to be an old and uninteresting idea…using traffic lights to symbolize each button function! The designers of course thought it was strange and boring BUT after a few weeks of trial, yeah it made all the sense to them…red meant close and green to expand.
The other thing that is very unique about Apple is their layman approach to problem solving. Steve Jobs remarked on Apple after taking over as its interim CEO in the 90’s, “I can’t find sex in apple machines anymore!” True eh? people got to relate more personally to the software they use!
The starting point of the iPod was not about a hard drive and a chip in a walkman. It was simply user experience! It meant concentrating on navigating content. FULLSTOP! Apple was paying so much attention to “saying no” to features that would make the iPod NOT simple.
Apple believes that the most important decisions you make are NOT the things that you do, but the things you decide NOT to do.
I think this is a very good approach for making things simple and easy. Less is more!
When it comes to user design and user design innovation, a lot of companies like to say and think that they are customer-centric. They approach their users and ask them what they want. This user centric innovation is driven by feedback and focus groups. But Jobs shuns laborious studies such as these where users locked in a conference room go through gruelling hours of no productivity. What one really has to do with the focus group is to just observe them and NOT listen to them.
What Jobs does is even much simpler. To Play with the new technology himself. He notes down his own reactions to it and gives his feedback directly to the engineers. Jobs believes that if the technology works for him it will work for others. Of course, one has to have a layman approach when playing around. Steve Jobs is neither an engineer nor a business expert. He is a master layman!
John Sculley the ex CEO of Apple says “ But unlike a lot of people in product marketing in those days who would go out and do consumer testing, asking people what they wanted, Steve didn’t believe in that. He said, ‘How can I possibly ask someone what a graphics-based computer ought to be when they have no idea what a graphics-based computer is? No one has seen one before!’”
Creativity in art and Technology is about individual expression. Just as an artist couldn’t produce a painting by conducting a focus group study, Apple doesn’t use them either. They try it themselves!!
I think this can apply for us as well. Toyota believes that every engineer should be a quality controller too. For us we got to design and test our own software and give critical feedback! More and more!! I see very many good ideas pop up during our internal design discussions and during development. Some of them get implemented straightaway. Great! But I think we just have to get better at it…better at critically analyzing what we do. I don’t mean to say that “we should start shitting on our own doorstep”, this is bad :-) I mean that we should do more constructive criticism of what we make…let it be design or coding. This I think will enable us produce easier solutions for our customers.
If Sony started believing on customer studies and feedback alone, they would never have released their famous walkman in the 80’s. The company did though invest a lot of money into market research before releasing the walkman. All the marketing research said that the walkman was going to fail dramatically. No one would buy it! But the founder Akio and his team believed strongly in their product and pushed it through anyway. It became one of the greatest hits.
It’s the same with Steve Jobs he does not require user groups because he himself is an user experience expert.
So why don’t we as visual/interaction designers and coders and salesmen spend more time on analyzing and testing the stuff we design and develop?
This will make our product easy to use! We got our core value in there, “We make it ez”
And the real reason Microsoft doesn’t fix Outlook?
Posted by PEZ in Innovation on June 27, 2009
When Microsoft created Outlook 2007 they took a mysterious design decision. “Let’s use the suckiest HTML renderer in the world (the MS Word one) to render HTML messages. ” Now it seems they’re planning to stick to that decision in Outlook 2010. To make the world aware of the nuttiness of this some good folks has created a site about it: Outlook’s broken – Let’s fix it
On Twitter there are more than just a few people who has struggled with downgrading their e-mail designs to be at least readable in Outlook 2007. Which made the news about this fixoutlook.org site quite big on the Twire. And Microsoft saw it. And Microsoft responded. Check it out. In the respons you’ll find:
Word enables Outlook customers to write … visually stunning e-mail messages.
That’s probably why Microsofts own XBox Live Team starts all their e-mail messages with this:
Read this online if you can't see the pictures or if you're using Outlook 2007
Seems like the XBox Live team doesn’t use Outlook? Or maybe they just don’t know how visually stunning their e-mail messages can get using it.
Microsofts response also contains this:
Microsoft welcomes the development of broadly-adopted e-mail standards. We understand that e-mail is about interoperability among various e-mail programs, and we believe that Outlook provides a good mix of a rich user experience and solid interoperability with a wide variety of other e-mail programs.
It’s of course a bad-taste-joke. But I think that the part about how they understand that e-mail is about interoperability is true. Unfortunately that’s where this decision probably comes from. Microsoft fears broadly-adopted standards. The world is about as stuck with Microsoft Office as it is with Windows. Wherever Microsoft has a near-monopoly they take the opportunity to fuck the world. That’s what they do with Internet Explorer. That’s what they do with Outlook. But what can we do? Maybe we can try get the EU to force Microsoft to quit bundling Outlook with Office?
Design Patterns: From Monkey to Man – Part I
Posted by Ram Sundararajan in Innovation on June 24, 2009
Recently we here in Bangalore were discussing different ways of doing things to make our software and work environment better. We were all convinced that one way to make our code better was for us all to help each other out to make our own work environment more fun to work. This was just one thing we all were convinced about anyway! Something to celebrate, Hurray!! :-) Of course, there were many different opinions about what it means to make it “better”.
At first sight we thought that it was our work processes that can make a difference in the way we write and perceive our code. Though, this influence can never be ignored, we believe that for a rapid growth company like ours, we programmers and developers also need to improve the way we think about code. We of course should be proud of what we have accomplished so far, but we got to remember as Olle would say, “it’s a marathon we are running for God’s sake!”. We need constant energy and effort to get it across the finish line.
We thought that for us and our code to look better, we got to think better. We got to be code designers and not monkey like application programmer. We need to get constant inspiration and fuel from other code writers and designers out there. We believe that the wheel has been already invented, i.e., someone else in the world would have already solved our problem at hand earlier and probably has a better solution! We just need to google for the right idea and steal it.
Steve jobs once remarked “Good artists copy and great ones steal!”
We steal better designs to be better designers!
So with the initiative from Jayesh we bought this book called “Design patterns: Elements of Resuable Object-Oriented Software” written by a geni called Erich Gamma (and 4 others). Ganesh started reading it first and gave us a nice 25 minute presentation this Monday morning when our internet line got down. We thought that it was a good start and wanted to continue evangelising our thoughts around code design.
We are thinking of doing a 3 blog series of “From Monkey to Man” depending on the popularity of this article. So please do give us feedbacks and counter arguments to encourage us write more on our reflections on Erich Gamma’s book.
Okay, thats enough of background info. Lets now jump start into what Erich sees in patterns…
Designing object-oriented software is hard, and even harder is designing reusable object oriented software.
How many times have you had the dejavu – that felling that you have solved a problem before but not knowing where or how? If you could remember the details of the previous problem and how you solved it, then you could reuse the experience instead of re-inventing the wheel again? The purpose of Erich Gammas book is to record that experience as “design patterns”
Gamma goes, design patterns capture solutions that have developed and evolved over time. Hence they are not the designs people tend to generate initially. They reflect untold re-design and re-coding as developers have struggled for greater re-use and flexibility in their software. Design patterns capture these solutions in a succinct and easily applied form.
Good object oriented designers will tell you that a re-usable and flexible design is difficult if not impossible to get it “right” the first time. Before a design is finished, they usually try it themselves, reuse it several times, modify it each time and then finally, you have a design that is “good enough” One thing great designers know NOT to do is to solve every problem from the scratch or from the first principle. Rather they want to re-use solutions that have worked for them and others in the past. When they find a solution to be “good enough” they use it again and again. Such experience & thinking is what makes them part of the greats.
Design patterns are NOT about designs such as a dictionary or a tuple or linked lists or queues that can be encoded in classes and reused as it is. Nor, are they complex, domain-specific designs for an entire application. They are descriptions of communicating objects and classes that are customized to solve a general or generic design problem in a particular context.
For instance, take the example of database connectivity, people have solved this in many ways and we do have our own standard. But do we really follow through the standards in all the places? Nope…the basics are that we need to connect to the DB once and only once per request and that it should be void of injection vulnerabilities. Why don’t we use singleton design pattern for this problem and the pattern will itself make sure to create only one connection even though your code attempts again and again?
The design patterns require neither unusual language features nor amazing programming skills or tricks. It can be implemented in Python although it might take a little more work than an ad hoc solution. But the extra effort invariably pays dividends in increased flexibility and re-usability. So, the question if is should we write the operation and function files in a procedural way? Nä, this is monkey work!
If we start designing our code with the back-drop of patterns in mind then we create more robust, re-usable and testable code.
Below are the arguments from Erich to use design patterns:
- Patterns make it easier to reuse successful designs and architectures.
- Expressing proven techniques as design patterns makes the codebase more accessible to new developers.
- Reduces the need for documentation
- Easier to maintain the system
- Put simply, design patters help a designer get a design “right ”faster and thus helps him/her reach the customer faster
I will stop here for now. In my next blog, I will talk about the details involved in design patterns…Erich has a solution for the three tier architecture (Model/View/Controller)!
Stealing is NOT bad afterall, it is clever! ;-)
ThoughtWorks conference on Scaling Agile
Posted by Ram Sundararajan in Innovation, Social, Values on June 9, 2009
As some of you might know, four of us here in Bangalore went to a conference/seminar at ThoughtWorks on ”Scaling Agile”. For those of you who do not know much about ThoughtWorks, they are a successful company with over 1000 employees in six countries. They are the fore-runners when it comes to Agile project management. ThoughtWorks also sells an Agile project management software called Mingle.
During the conference, it was very exciting to see how similar our work framework was to theirs. Does this mean that we are on the right track? Oh yes; not only by following one of the Agile principles of “reach the customer faster” but also by following some of our core values very effectively.
Right, below is what ThoughtWorks had to say about how someone whom they call an Iteration Manager should try to establish in his/her team (this role is bundled in the role that Lena and Jojo are doing at present…)
Iteration Manager should work toward a professional and accountable work environment. Such environments exhibit proper behaviors and mannerisms, such as the following:
- Mutual respect is displayed for self, others and customers
- Successes are celebrated
- Mistakes are treated as learning experiences
Strikingly relevant to what we already have, isn’t it? I will post you this book today.
Okay, going back to the conference, below are the key points we learned from there
- Programming is an art and software development is a social activity – Improve the conversation and you improve the software
- Embrace change – Dare to make a difference
- Rapid feedback – Develop to make your MUST HAVE work faster. Get rapid feedback from the customer. In our case, UxD and Test
- Continuous Integration – Check-in your code often. Create a test harness like Unit test and functional test simultaneously
- Face to face communication is a must – ThoughtWorks does it using video conference, chats, etc
- Make yourself easily accessible
- Make dev. Environments close to Production.
Apart from these, ThoughtWorks stresses on the importance of graphing out our project activities so that the Project Team and the stakeholders can find out the bottlenecks in the project now and then. I do not think that we do it today but they talked about the importance of maintaining charts which can be discussed on a weekly basis. This chart becomes more interesting especially during the retrospectives, if not immediately.
It was interesting to see how they keep track of the number of check-ins a day through a graph. At ThoughtWorks they say that they have a general rule that whenever a developer checks in a code, s/he is responsible for the aftermaths. If a bug is found in the recently checked-in code, it’s the developer’s responsibility to see to it that the bug is fixed or the code is rolled back within 5 hours.
When it comes to practicality, I would like to jot some things on the Continuous Integration part. I think that we have completely missed out on this part when we moved to the new Harvest model. ThoughtWorks has MOSCOW requirements in the product backlog. When the project is under implementation, the development team discusses the design aspects and implements the most important MUST have ASAP. They check-in their code (they said 20 times a day) to the main branch, and write unit test and functional test simultaneously and make sure the automation test passes really at the beginning. The test and the design team then picks up the task and works with them. Thus overcoming the “continuous waterfall” pitfall in the development cycle. The dev, design and test team work simultaneously on the tasks. Fantastic!!
We tried something similar to what they suggest here May sprint and it seems to have worked well for us. But again, we all in our roles need to make ourselves more accessible, else we will end up in the continuous waterfall.
Below are what ThoughtWorks thinks are challenges and options to overcome when it comes to scaling Scrum
|
Challenges |
Options |
|
Limited face to face |
Formal and scheduled communication channels like meetings chats, video conference |
|
Consistent view of big picture |
Scrum of Scrums |
|
Lack in clarity of responsibility/ownership |
Information radiation
|
|
Decision making |
Improve escalation points |
|
Knowledge sharing |
Communities and forums |
Below are the key take-aways from the presentation ThoughtWorks did during the conference.
- Program plan and governance – By governance they mean communication
- Continuous Integration
- Trigger points for structural changes – We need to get red hot at things that work less good and burn to improve it ASAP
- It takes more time to change
- Focus on Objectives, Principles and ADAPT!
Oosch! You know what? I think that the next time you guys come down here, we should make a visit to ThoughtWorks. They really have an open, flat, motivated and a smart work environment!
The Devil doesn’t need an Advocate!
Posted by PEZ in Innovation on May 27, 2009
Back in the days when I was owner of the vision, head of development and product manager of a dotcom startup I had this really great boss. He was creative, supportive, caring, trusting, fun, really intelligent, self confident and, well, he had most all of those treats you wish all your bosses should have. Yet, he used to do one thing that puzzled and even annoyed me at times. It was when we were preparing for a meeting.
I have this way of always trying to be on the offense and to own the initiative. Not always succeeding, of course, but I imagine that thinking positive will help. I guess I’m a incurably naïve.
My boss of back then also was one to want to own the initiative. But he, generally, had a different approach. He played it defensively. Covering all bases. To do that you need to be able to think negatively. There’s the source for my annoyance. I just have a hard time following the line of thought when it goes the negative way. When preparing meetings I had to endure my boss when he raised the arguments against our case. What if they say this? What if they argue that? To me it’s “So, what if? Our offer is excellent! Let’s focus on exposing that!” I don’t want to cover all bases. I don’t want to imagine all the shit that can happen.
Yes, I’m biased. But I honestly think that my general approach is better. Go full force with your thing! If you feel it’s not good enough to throw your full support behind it, then chose another thing. Make sure you work with something you really believe in. And hone your blade. But hone it for attack. For defence trust your reflexes. Apply positive thinking. Playing the Devil’s advocate just drains your energy resources. At least it has that effect on me.
Addendum June 11 2009: I wrote this article when I was a bit upset. I’m glad that I did, but still, I think I should have asked Joakim Ohlrogge to write instead. Here’s his take (pasted from the comments):
A thought: I despise DAs more than I like them. But the question is if it is really DAs I despise or if I despise idea-poachers. It’s hard enough the get ideas to fly even without having a sniper shooting them down before they take off. It’s often all too easy to come with a “what if” and I’ve experienced some people who make it their task to figure out every obscure situation that could possibly go wrong. There needs to be some rime and reason. You can always find something that goes wrong, after all, we work with software.
I would not want to be without DAs but I don’t want them to take up more time than daring enthusiasts do. Also, they are not there to prevent disasters, they are there to inspire different though paths. A DA can never replace the ability to respond promptly when “shit happens”.