Slides of my talk yesterday on programming language selection (from a technical and a business perspective)
Background article (not exactly same but on a similar topic) : Improve your web based software development and maintenance ROI with dynamic programming languages
Talk Announcement : Seminar: Strengths and weaknesses of various programming languages – 28th March
While not primarily a Functional Programming (FP) language, python has long had a modest support for many of the constructs supporting FP. A while back I was studying Monads and Haskell and was curious to see if some of these constructs were applicable in the problem domains I was working on. I did run into a block very soon since Haskell/Monads have a support for invoking different functions based on type and that support is important for the way many of the constructs are modeled. However method overloading is not feasible at a language level in Python, and thus its difficult to create similar constructs.
A month later I ran into this article Tighter Ruby Methods with Functional-style Pattern Matching, Using the Case Gem which again piqued my interest in the same matter. Thats when I looked at the topic once again and came up with the following similar example (similar to the one in the blog post referred to), to demonstrate constructor overloading.
Note that method overloading is not consistent with duck typing approaches for many. However many a time we do run into a situation where conditional logic is required based upon types. As one attempts to bring in a more FP oriented style, I suspect the need for type matching is likely to only increase. As an example you may have a reference to a
1 | stream |
variable which you need to interpret differently based on the format, say xml or json. In such case one approach is to have two functions
1 | parse_as_xml(stream) |
and
1 | parse_as_json(stream) |
What the construct below allows you to do is to have a common function around the two
1 | parse(stream) |
which can switch between the two internally.
class X(object):
def __init__(self, *val):
# Matcher functions. These return true or false for the type matching
# Possible enhancement could be to have generic function
check_dict = lambda x : isinstance(x[0],dict)
check_sequence = lambda x : hasattr(x[0],'__iter__')
check_args = lambda x : len(x) == 3
# Type specific initialisers
def initialise_from_dict(hash):
self.first_name = hash['first_name']
self.last_name = hash['last_name']
self.age = hash['age']
def initialise_from_args(*args):
self.first_name = args[0]
self.last_name = args[1]
self.age = args[2]
def initialise_from_sequence(seq):
self.first_name = seq[0]
self.last_name = seq[1]
self.age = seq[2]
# Matching data. This is the switching data based on which the appropriate
# function is called.
dispatch_data =((check_dict,initialise_from_dict),
(check_sequence,initialise_from_sequence),
(check_args,initialise_from_args))
# The switch
for check,func in dispatch_data :
if check(val) :
func(*val)
break
def __str__(self):
return "%s %s(%s)" % (self.first_name, self.last_name, self.age)
print X('hello','world',33)
print X(('greetings','earthlings',44))
print X({'first_name' : 'john','last_name' : 'doe', 'age' : 45})
Essentially it boils down to create a list of function pairs, the first to be executed to check if the second should be performed. Some of the characteristics of this approach are :
One of the possible enhancements to this could be to have a generic pattern matching function and make the first argument in each of the items in the matching sequence (
1 | dispatch_data |
in above case) be some pattern data which results in the pattern matcher function returning a
1 | True |
or a
1 | False |
.
This is not the only way to overload but I found it amongst the easier and simpler structured approaches.
Agility and Process Maturity are two very different terms to me. I have been rather pleased with the results I have found after having started working with agile methodologies more than 4 years ago. That makes me a candidate for being a biased blogger. But it still does allow me the ability to state my views clearly on the topic after that explicit disclaimer.
Process Maturity (especially CMM and ISO oriented maturity) focus on ensuring consistent, measured and self improving quality of output. This is achieved through multiple checks and balances, and detailed documentation of processes, and regular audits to identify points of weakness and their redressal. At least to the extent I have been exposed to them, people are looked at as cogs in the assembly line (replaceable and faceless) and focus is on ensuring that the assembly line works at a consistent pace even as people move around from job to job (or from assembly line to assembly line). Thus the focus is on setting expectations at modest levels and ensuring that these expectations can be met even as various events occur which introduce risk into the process, since the process methodology and documentation is geared to help address many of these risks.
Agility on the other hand probably stemmed from some of the concerns around the non-people-centricity and heavy-documentation-focus of these process maturity models. It instead ended up focusing on Individuals and their Interactions and on accepting the necessity of Change and thus adopting it wholeheartedly as an aspect that is inevitable and thus best accepted as a feature rather than a bug. Thus rather than slowing down the delivery, it attempts to substantially speed it up by removing many process steps which may seem to be impediments to progress. While substantially reducing most control and measurement points such as documentation, reviews, audits, they replaced them with steps which allowed quality to be maintained by introducing higher skills and discipline into the people (test driven development, pair programming, daily scrum).
Thus if a development team tells me they follow a process maturity model, assuming they are being completely honest in that statement, it tells me that as a customer I can expect them to set a pace and generally largely stick to it with incremental improvements while shielding me from having to deal with many of the internal risks they battle with.
If on the other hand a development team tells me they follow the agility model and again assuming they are being completely honest, it tells me they have a lot of respect in their own capabilities and to their ability to adaptively deal with internal risk through better earlier risk detection and redressal (Test Driven Development / Continuous Integration etc.) rather than through process oriented controls such as Documents / Audits / Reviews etc. I would also generally expect a much much higher productivity and quality from the team but with a higher statistical variance.
Ceteris Paribus, as a customer I would feel that the Agile Team is likely to introduce more schedule risks in situations of higher person turnover or lesser developer disciplines, while the team that focuses on Process Maturity is more likely to introduce schedule risks in situations of changes in requirements or in situations where a very quick time to market is called for.
What is obvious to me is that these methodologies have been defined with very different attitudes. If we play a “one word that comes to your mind” game with the terms, its “power” with “agility” and “control” with “process maturity”. Both are important and desirable and play a role, but the slider is positioned differently in each of the cases.
It has been rather obvious that agile processes have been occupying a greater mindshare over the past 5 years (the same thing happened with process maturity methodologies in the decade before that). I had been concerned that, as with many other trends in Software, the word Agile might also start getting abused where people start using it quite differently, to leverage on its momentum and the mindshare. It has been happening for a while, but the article Strategies for Scaling Agile Software Development The Agile Process Maturity Model just blew me off. I have only the greatest respect for Scott Ambler and especially for all his writings on Persistence. But in this article all the agile methodologies have been clubbed together as “Level 1 development” and many of the rather heavy weighted processes some of which probably led to the formation of the agile alliance in the first place are listed in the “Level 2 (disciplined) delivery”. I must clarify that agile software development covers all aspects of lifecycle including testing and measurement and agile software methodologies deliver as well (contrary to what the article “seems” to suggest) and rather than building discipline into processes, reviews and audits it builds discipline in the people that form a part of that process.
Since agility and process maturity are based on different attitudes I can’t see how one says I am going to put both the things together unless one intentionally and quite deliberately repositions the slider at a level with offers lesser power than agility and also dilutes process control compared to process maturity. But thats not the impression I got from the article. It seems to suggest that one can take these “level 1″ agile processes add “level 2″ disciplines to it and then add some uncertain “level 3″ elements to them to make things better than where they stand today, something that I am a little skeptical about.
So when a development team tells me they are following the “agile process maturity model (APMM)” I am likely to believe that they are either (a) too confused, (b) want to appear to leverage the agile momentum while using the strict control regime or (c) successfully figured out a way to move their slider somewhere in between with the risk that they lost some of the best elements of the two methodologies while attempting to lose the worst.
Having said that, it will be interesting to read Scott’s future articles on topic and to follow this trend. I have been proven wrong in the past, and it could happen again for me to have to eat my words. But moving that slider between power and control to attempt to achieve the best of both seems a little risky, and you can be sure I am unlikely to be an early adopter for the fear of getting severely burnt.
Update :I forgot to add that amongst the many items listed in Level 2, those such as (throwaway) sketching, whole team, test-driven development (TDD), continuous integration, daily standup meeting are accepted aspects of typical agile methodologies whereas those in the level 2 methodologies which agilists often avoid as actively managed and maintained charts are not even listed eg. in case of RUP – use case diagrams, class diagrams, sequence diagrams, state diagrams. So what is the contribution of other methodologies such as RUP in this case is largely unclear. I do not know the other Level 2 methodologies so can’t comment on the same.
This blog post is not about twitter API programming, though thats what it does deal with. It focuses on the intermediate level infrastructure (ie. higher than the HTTP/REST APIs exposed by other sites but lower than the class libraries that surround those) necessary to work with HTTP/REST based APIs being offered by various web sites.
I have been working on scouring and analysing twitter data for which I have been having to work with continuously accessing twitter on a sustained basis for a number of days. I started refactoring my code recently, and this blog post details the results of that exercise. More specifically in the context of invoking HTTP APIs it deals with the following aspects (many of them which are specifically introduced due to twitter.
I have specifically focused on creating a pipelined design which might be an interesting design aspect for many in this situation, and have primarily relied on python based generators for the same though similar functionality could be built using Iterators in other languages as well.
More…
Interesting post by Scott Berkun : How to deal with jerk programmers which isn’t exactly consistent with my experiences from both sides of the fence.
Scott states
The best place to start is empathy. Why is someone acting like a jerk? There are basic psychological reasons for this: Either they are insecure, they are unhappy, or they are angry about something.
Ok, there is a fourth reason, that they are psychopathic hell spawn put on the earth to torture all living things in a 10 foot radius, especially you, but lets assume that’s not the case for a moment.
That fourth one sounds eerily like me, but I shall pretend thats not the case. Scott further goes on to make a set of suggestions (read his post for details, I am just listing them below)
While definitely in the right direction, these are very tactical steps. And I really am not sure that the jerk programmers can be “unjerked” with these. There are two types of jerk programmers. Those who simply enter the office with a combined sense of arrogance and disdain that the situation is likely to be beyond any reasonable likelihood of any decently workable relationship. Thankfully this is likely to be a very rare set (I suspect they exist, but haven’t ever worked with one). At least half of the remainder are likely to have some issue with the “big picture” work atmosphere. Something that reeeallly bothers them. Something they are finding difficult to reconcile to. Something thats gnawing at them.
I think there are two options in this case. If you can largely agree with the issues, ensure that you not only empathise and help (as Scott mentions) but also make sure you’re clearly seen to be believing and acting towards solving the issues. I think that belief is a very important element which sets up a shared goal and is complemented by the actions and results. The programmer needs to believe you are on the same side (in his opinions the right side) of the issues as him many times even if not completely so. This could be related to number of aspects – technology choices, code or design quality, deadline tradeoffs, deadlines, territorial control issues etc. etc. A programmer is very unlikely to actually promote himself to jerkdom because of the coffee vending machine being located on the wrong side of the aisle or even due to more serious matters such as role ambiguity or disagreement. It usually runs much deeper.
In case you cannot agree with the issues, I think a clear talk needs to be had about the differences, the criteria that are going to be laid down, and the programmer should be encouraged to either adjust to these or attempts should be made to find a role / position where such differences can be minimised. In extreme cases it may be helpful to encourage the programmer to relocate to other teams for a win-win resolution.
To summarise, if a programmer is acting like a jerk, there’s likely to be a much deeper issue. Work with him, be seen to be friendly to and believing in his case and be seen to be on his side many times on the issue and demonstrate at least some tangible progress on the issue at regular intervals. Alternatively in extreme cases find avenues to work independently. There is a risk of lesser tactical resolutions simply prolonging the difficulties for all concerned.
|
 |
