December 12th, 2009 by Moti Karmona | מוטי קרמונה · 2 Comments
This is my recommended check-list for high level design review.
*********************************************************************** *** keep it simple and make sure it answers all the requirements ***
***********************************************************************
Reverify your Requirements
Functional specification, use cases and requirements are clear and publicly documented
August 10th, 2009 by Moti Karmona | מוטי קרמונה · No Comments
Recently, I have encountered an interesting paper (2006) about Chubby – Google’s (Paxos based) distributed lock service.
I was especially amazed by the observations made on the Google engineering capabilities and mindset inside a “formal” research publication.
Although one can easily get into a cynical state of mind reading this paper… I feel that this “pragmatic view” which combines a deep architectural and algorithmic know-how with keen understanding of the social factor in software development is exactly the key to create legendary software.
Anyway, very well written – highly recommended reading…
“Our developers sometimes do not plan for high availability in the way one would wish. Often their systems start as prototypes with little load and loose availability guarantees; invariably the code has not been specially structured for use with a consensus protocol. As the service matures and gains clients, availability becomes more important; replication and primary election are then added to an existing design.”
“Developers are often unable to predict how their services will be used in the future, and how use will grow. A module written by one team may be reused a year later by another team with disastrous results … Other developers may be less aware of the cost of an RPC.”
“Despite attempts at education, our developers regularly write loops that retry indefinitely when a file is not present, or poll a file by opening it and closing it repeatedly when one might expect they would open the file just once.”
“Developers rarely consider availability. We find that our developers rarely think about failure probabilities.“
“Developers also fail to appreciate the difference between a service being up, and that service being available to their applications.“
“Unfortunately, many developers chose to crash their applications on receiving [a failover] event, thus decreasing the availability of their systems substantially”
November 21st, 2008 by Moti Karmona | מוטי קרמונה · 4 Comments
“You can always start a weekend experiment but you can never know how it will end” (Moti Karmona, 2008 ;)
I was very curios and wanted to take the GAE for a quick test drive but the Google documentation have few inaccuracies and isn’t sufficient if it is your first Python encounter so I lost three hours of precious beauty sleep and compiled this blog-post-capsule for future generations.
Help –> Software Updates –> Available Software –> Add the http://pydev.sourceforge.net/updates site –> Install it –> Restart Eclipse
Configure Eclipse to use the Python interpreter by navigating to Window –> Preferences –> PyDev –> Interpreter –> Python –> New and select the location of python.exe on your system
Create your first project
File –> New –> PyDev project and click next –> Name your project and make sure Python 2.5 is selected.
Add necessary App Engine libraries to your project | Right click your Project folder –> Properties –> PyDev – PythonPath (see image below)
Open a command prompt and navigate to your application directory.
Type appcfg.py –email=yourgmailaccount@gmail.com update src\
To publish code within Eclipse, open Run –> Run configurations and make a copy of your previous run configuration. Change the Main Module to appcfg.py, and change the argument tab to –email=yourgmailaccount@gmail.com update ”${project_loc}/src”
Your code is now live! Test it by going to http://yourapp.appspot.com
November 2nd, 2008 by Moti Karmona | מוטי קרמונה · 2 Comments
Last weekend I was wasting time on my Blog performance and all I got is 10 sec. and this lousy post.
Quick profiling with FireBug and YSlow FireFox extensions have done great wonders with my amazingly slow, not-really-that-interesting, hosted (webhost4life) WordPress blog.
October 28th, 2008 by Moti Karmona | מוטי קרמונה · 1 Comment
Yahoo have released the Y!OS (Yahoo Open Strategy) 1.0 platform.
This is a cool set of simple APIs that can give you access to everything you ever wanted in Y! but was afraid to ask for…
Yahoo! Social Platform (YSP) // The Yahoo Social Platform is a set of RESTful APIs for Profiles, Connections, Updates, Contacts and Status.
Yahoo! Query Language (YQL) // The Yahoo Query Language is a web service that functions much like SQL (see example below)
OAuth Authentication // OAuth is the authentication and authorization standard Yahoo has decided to use when giving third parties access to Yahoo user data.
Yahoo! Applications Platform (YAP) // Currently very limited and in a restricted sandbox.
________________________________
Example: How to use YQL APIs to access MyBlogLog profiles?
Simply ask for all the community members of MyBlogLog community with this YQL:
select * from mybloglog.members.find where community_id in (select id from mybloglog.community.find where name=”Karmona Pragmatic Blog”)
And once you have the IDs you can ask for my personal profile by:
select * from mybloglog.member where member_id =”2008070609482910″
Well… together with the existing BOSS API, this set of APIs is a powerful enablers to the Y! development network and I am sure some cool stuff are going to emerge from this innovative move…
Amazing!!!
________________________________
* You can have more YQL experiments using the YQL Console
** Boss Hack Day is coming to Tel-Aviv | November 6, 2008 @ Feature (!!!)
October 4th, 2008 by Moti Karmona | מוטי קרמונה · 2 Comments
When “The Moscow Cats Theater” came to New York, the Russian clown Yuri Kuklachev was interviewed: “the secret of training them is realizing that you can’t force cats to do anything [...] If the cat likes to sit you can’t force her to do anything else [...] Each cat likes to do her own trick [...] Maruska is the only one who does the handstand. I find the cat and see what they like to do and use that in the show [...] I have a cat now that loves to be in the water…”
When you go out of your way to hire the best people around than soon enough you will find yourself herding a superior, class A, hyper-developed mutant Ligers* who are much more knowledgeable than the herder (a.k.a. you)
In this environment you have to learn to simply trust your people (although this is not simple at all :), mark the vision, let them loose and only help to get rid of the stones in their way (this concept was best described as the Open Kimono** policy in Peopleware)
Well…. Managing the Delver Engineers is like Herding Legendary Ligers and you need to make a superior effort to see what these ligers “likes to do” and run fast enough to set the Vision and move the rocks out of the way.
__________________________________________
* The Liger, is a (huge) hybrid cross between a male lion and a female tiger
** Open Kimono Attitude: You take no steps to defend yourself from the people you have put in positions of trust.
By the way, The best answer I found on the origin of the term “Herding Cats” was in Google Answers
February 22nd, 2008 by Moti Karmona | מוטי קרמונה · No Comments
1st Warning: Chaotic post below
Software project are chaotic system and are highly sensitive to their initial conditions (a.k.a. the butterfly effect) and dynamics (e.g. wrong design, vague requirements, team professionalism etc.).
To master (/control) a software project you must be able to breathe (/smoke ;-) the project – inhale the chaotic butterfly movements around you and exhale with the needed adjustments or you will be crushed on the nearest project failure shore with zillions of butterfly excuses.
2nd Warning: Smoking software project is bad for you health
After a decade of software projects smoking I find myself easily doing a background-surfing on the chaotic edges of my projects like I drive my car in the same daily well known route back from work but since I am part of the same chaotic system I am trying to control, I know that my background-surfing is like forgetting my own butterfly wings.
Software project smoking isn’t a social event and can’t be easily shared but it is also one of the key factors in projects surfing – If you will not be able to share your surf experience with your team, your own butterfly wings will bring the next tsunami.
3rd Warning: Don’t practice management if you don’t like the butterflies
November 8th, 2007 by Moti Karmona | מוטי קרמונה · 1 Comment
My rough estimation is that the number of software project managers in the world is smaller in (at least) one scale from the conceived time-estimation techniques and this post is my humble four-cents contribution on how to do pragmatic time estimation for software projects (just finished one in Delver).
Start with the mother of all lists to store your Product Manager wish list– We use eScrum Product-Backlog to store our work-items
Prioritized them – We use 0-Yesterday; 1-Must; 2-Important; 3-Nice-to-Have and 4-”Forget-About-It”… ;-)
Get relative estimations on all items
Granularity is the bronze-bullet for time estimations – Strive to the finest grained possible in reasonable time-frame e.g. We usually aim for 2-5 days granularity in 2-3 days of time-boxed-estimation-period since the finest granularity in planning without reasonable time-box might take twice the time of doing the planned work (a.k.a. The Estimation Paradox)
Experience can turn your bronze bullet into silver one (ye ye, a silver one) – Relative estimation is calculated relatively upon a common scale of known work items from the team history e.g. We use Scrum “Story Points” and constantly measure the team velocity for time estimation adjustments
Fibonacci sequence (0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89 etc.) can be used to “embed” the complexity and risk of rough (with insufficient drilldown) estimations e.g. if your estimation granularity for specific task reach ~40 days then your pragmatic estimation should be around 55 days (= the closest Fibonacci sequence) since it is reasonable to believe your (insufficient) granularity conceals risk, complexity and unknowns issues which requires Fibonacci-like-”buffering”
Strive to synchronize your time estimation techniques into very simple one – different time estimation conventions in the same development team is the 2nd reason for time delays. (I will give 0.95$ grant if you can guess what the 1st reason)
I know I am different but personally, I do prefer to have “pragmatic hours” vs. the normal Agile “ideal hours” and to start the project when 1 “Story Point” = 1 “Pragmatic Day” so long everyone understand this will change as soon as you start the project and then you need to return to velocity tracking to calculate the end
Don’t be naïve (a.k.a. “Ideal Days”) with two known flavors:
Optimistic time estimations, assuming 24*7 of concentrated programming ability with no outside interference (a.k.a. no such thing)
“Stupid” hand-waiving time estimations a.k.a. It is only 10 min to code this (but ~5 days to Integrate, Review, Design, Test, Schema and DAL changes, I18N support, Styling etc.)
Get the rough project estimation = Sum of all product backlog story points / 22 (work days in month) / Number of relevant people
Usually this calculation will show you don’t have enough time for the project (even without project dependencies buffer which can be added later)
Start the “Tradeoff Game” – Try to cut items (content) based on the relative ROI
Revalidate your priorities since they will be the main tool (beside dependencies) for creating the project work plan.
As I see it, estimating software projects in a realistic time-frame is a statistic prediction of chaotic, time-delay-series of events and will never be straightforward nor easy so you can only do your best in the estimation and then track the project as it goes and make the needed adaptation on the way upon crystal clear project priorities.
