Youry's Blog

Youry's Blog

Archive for September 2012

Is ‘pair programming’ in your future?

leave a comment »

  1. Good discussion about Agile and Traditional SW Engineering at LinkedIn Harwood • I have been in the fortunate position of using both formal methods and agile methods in industry. The point of balance between two is interesting. Formal methods are often overwhelming for the average development. In many cases the development in hand cannot benefit from formal methods as such either because what is being developed is so common place that formalising adds nothing to the understanding of what is required or because the requirements are so under specified by product managers that what is actually taking place is an exploration of the design space using prototype code (that may actually become the product).

    The latter point is worth expanding, those that specify products rarely have the skills to understand formalism, they only grasp the dynamics of a system by seeing it “in flesh” as a (partially) working system.

    In my experience agile methods have proved quite effective at rapidly iterating the product development in these circumstances.

    Now this sounds very negative for formal methods. However this is only one side of the story. Certain aspects of systems need formalisation and, indeed proof. For example, one major area of design that developers constantly get wrong is concurrency. I have known several projects where the concurrency/synchronisation design arrived at by informal reasoning has been catastrophically wrong. The way out of these problems has been to do a formal design of the handlers for this part of the product and to prove it has the desired behaviour.

    I cannot end without adding a couple of comments on what affects the effective of the two approaches.

    For agile techniques, it has seemed to me, that the real determiner of their effectiveness has been the degree to which a common understanding of the product and code models to be used can be instilled into the team prior to development loop. That is to say that the use of techniques, such as the CRC card game, played by the team to gain a shared understanding of how the product works, and what constitutes the elements of value to the customer, has a deep impact of the effectiveness of the subsequent cycles of the agile . It is simply all too easy for inexperienced teams to “loose the plot” and to confuse completing a piece of functionality with completing a piece of value.

    For formal methods the problems are somewhat different. One major problem is the semantic distance between formal methods and programming. If you develop a model of concurrent system in CSP or CCS, for example, the primitives that you use in creating the model are vastly different from the programming primitives you have at your disposal to implement the system. The developer quite rightly asks at this point “why should I build a model that is so far away from the code I will need to write?” and “how is the model connected to the code?”. There are, of course, two distinct way to address this problem, either we can design programming languages with better primitives that reflect the formal frameworks we have or we can create formal frameworks that are nearer to the programming primitives we have in practice. On this latter point we should remember that, for example, CCS and its subsequent developments, have been pursued to understand the fundamentals of concurrency, not as a vehicle for building systems.

    Apologies to all if this has turned into a bit of a rant 🙂

  2. Is ‘pair programming’ in your future? By Toni Bowers September 17, 2012, 6:52 AM PDT, published at

“Takeaway: Some claim that sharing a desk and one computer with another programmer is the most efficient way to code.

I’m not a programmer so I cannot speak for those who code for a living, but here’s a concept that could take some getting used to: pair programming. This is where two people share one desk and one computer, with one person being the “driver,” controlling the keyboard and typing in code, and the other being the “navigator,” monitoring design and scanning for bugs.

It all started with a book: “Extreme Programming Explained,” written by Kent Beck, creator of the Extreme Programming and Test Driven Development software development methodologies. According to the book, software should be released quickly and improved along the way. This is best done more quickly, according to Beck, by double-teaming projects.

Beck practiced pair programming at a software company in the ‘80s with Ward Cunningham, the developer of the first wiki. Cunningham asked Beck to check for bugs in a software application he was working on. As time went on, the two would pair up to knock out assignments so they could move on to their own pet projects.

The practice is spreading. Pivotal Labs, a software-development shop that was bought by EMC Corp. in March, has its 175 engineers pair all day, every day. Facebook has begun using the practice, as has the San Francisco-based company Square, which says about 15 percent of its engineers pair full-time.

And there are different versions of paired partnering as well: Playing the field, or changing partners daily, is called “promiscuous pairing.” Hopping back and forth between partners is called ping-pong pairing. Even those who work remotely can take part: Remote pairing lets programmers share the same screen via the Internet.

Not everyone is onboard with the concept. Australia-based software company Atlassian created a mock instructional video called “Spooning” that hilariously mocks the practice.

So what do you developers say? Is this something you would be comfortable with?”


Written by youryblog

September 21, 2012 at 10:25 PM

Java has become one of the weakest links in a PC’s and Mac’s defenses

leave a comment »

“Java, the programming language designed to make the web fun and interactive, has become one of the weakest links in a PC’s and Mac’s defenses against external threats. Consider the most recent Java vulnerability, a weakness currently being exploited by malware distributors: When Oracle, Java’s maker, released an emergency update to fix the software, security analysts reported that even the hot-off-the-presses code contains additional vulnerabilities.”

Written by youryblog

September 21, 2012 at 6:56 PM

Posted in SW Eng./Dev., Warning

10 reasons why your boss is a jerk by Elizabeth Bromstein| Sep 17, 2012

leave a comment »

I Found this paper is really interesting and make a sense (especially if you was a boss in the past or you are now):
“People love to complain about their bosses. People like to complain about their bosses so much I sometimes find myself wondering how it’s possible that SO MANY people who are apparently both totally useless and totally evil manage to get into such senior positions. I mean, if I believed half of what I heard, I’d think there was some conspiracy afoot to promote only incompetent minions of Satan.That’s, of course, not true. Most bosses are just trying to make a living.

But we’ve heard it all, haven’t we? So I used those complaints, conducted a survey – and used the internet, of course – to compile a list of reasons people hate their bosses.

If you’re in charge of a team, you want to be liked. Don’t listen to people who tell you it doesn’t matter. It does.

Here are 10 reasons why employees hate their bosses. Some of these are the same reasons your co-workers hate each other, which we recently discussed. OK. Onward…

Why you’re a jerk, Boss:

You’re not qualified to tell people what to do, or at least they don’t think you are: A recent study by talent management firm DDI showed that nearly half of employees feel they’re better qualified for their bosses’ jobs than their bosses. Be aware of your limitations.

You’re condescending: It’s never acceptable to be condescending (and even worse if you’re not qualified!). Who do you think you are? Be respectful of your employees at all times and never talk down to them.

You don’t listen: Listen when people talk to you. The same DDI study showed 35% feel that their bosses never or rarely listen to their concerns.

You fly off the handle: I hear stories about bosses who have screaming fits or throw tantrums. If this is you, cut it out. Anger is your enemy. You look like an idiot.

You’re too demanding: You ask people to do extra work, stay late, and pile and pile and pile things onto their plates. This is understandable. The demand is usually coming from above you, but be aware that people are going to hate you for it.

You’re too casual: A lot of bosses try to be one of the gang, like Steve Carrell’s character on TV’s The Office (I actually hate that stupid show) but it’s difficult to be buddies with people, then expect them to respect your authority. It shouldn’t be. This isn’t your fault. But it’s true.

You’re grouchy: I once had a boss I HATED. She was just a sour witch, all the time. In retrospect, she was probably just stressed out, unhappy or…I don’t know…suffering from mental health issues. Crap rolls downhill. So, you’re probably grumpy because someone higher up is stressing you out. But don’t take it out on your team.

You don’t give compliments: And you only give negative feedback. That is the worst. Your team does their job correctly, even exceptionally, 95% of the time, but you only open your mouth to point out mistakes and never give pats on the back. When someone does a good job, say so. Say it loudly and say it often.

You take credit for other people’s work: We know you do it and we can’t say anything about it. You say things like “I came up with…” or “We did…” when in reality you did nothing and someone else did it all. You’re a jerk.

You’re a weasel: You’re so concerned about your own neck that you don’t have your team’s back when something goes wrong, and you throw people to the wolves. Shame on you.

Ever had a boss you hated? Tell us about it. We won’t tell. We promise.”

Written by youryblog

September 21, 2012 at 9:36 AM

Posted in Business, Interesting

UML and ???

leave a comment »

Good paper about UML and it’s problems: UML & Users Concerns:

“Whereas UML has been brought to existence by very wise men under very propitious skies, the initial enthusiasm and first successes have never been transformed into wider acceptance and customary usage; subsequent updates and extensions didn’t help and may even have triggered some anticlimax. More than fifteen years after its launch, the utilization of UML is very limited, both in breadth (projects developed) and depth (features effectively used).  Moreover, the UML house is deeply divided and there isn’t much consensus among the few that use it seriously, principally to support domain specific languages (DSL).” … see more here: UML & Users Concerns

From LinkedIn discussion:

Three interesting discussion prompts from Hal Abelson ( and Gerald Sussman (

  • “Programs must be written for people to read, and only incidentally for machines to execute.”

Written by youryblog

September 18, 2012 at 2:44 PM

SW Engineering Standards

leave a comment »

Some posts about SW Engineering Standards:



IEEE Standards – any guide for the perplexed?

I’m working on a survey of standards for software development and assurance. The last printed collection I have (1994) lists 27. I went to the IEEE standards web site, and a search on “software” returns about 450 items – some are clearly not relvant, but I’m not sure about some.

Also, it looks like some ISO standards are now merged (?) or titled as IEEE standards, and/or vice versa.

Is there a taxonomy, road map, ontology, or some thing like that explains and relates topics, both within the IEEE standards? With respect to those of other standards bodies?

Search: Standards

IEEE SA – 1490-2011 – IEEE Guide–Adoption of the Project Management Institute (PMI(R)) … … edition) Working Group Oversight Committee: C/S2ESC – Software & Systems Engineering Standards Committee Sponsor: IEEE Computer ……


Written by youryblog

September 13, 2012 at 8:30 PM

Separation of Concerns

leave a comment »

Separation of Concerns Posted by Hayim Makabee on February 5, 2012 on

Separation of Concerns

Posted on February 5, 2012

The most important principle in Software Engineering is the Separation of Concerns (SoC): The idea that a software system must be decomposed into parts that overlap in functionality as little as possible. It is so central that it appears in many different forms in the evolution of all methodologies, programming languages and best practices.

Dijkstra mentions it in 1974: separation of concerns … even if not perfectly possible is yet the only available technique for effective ordering of one’s thoughts”. Information Hiding, defined by Parnas in 1972, focuses on reducing the dependency between modules through the definition of clear interfaces. A further improvement was Abstract Data Types (ADT), by Liskov in 1974, which integrated data and functions in a single definition.

In the case of Object Oriented Programming (OOP), encapsulation and inheritance proved to be essential mechanisms to support new levels of modularity. Design-by-Contract, proposed by Meyer in 1986, provides guidelines of how to improve interfaces using pre-conditions and post-conditions. Finally, the separation of cross-cutting concerns is the most important motivation for the proponents of Aspect Oriented Programming (AOP).

Since the first software systems were implemented, it was understood that it was important for them to be modular. It is necessary to follow a methodology when decomposing a system into modules and this is generally done by focusing on the software quality metrics of coupling and cohesion, originally defined by Constantine:

Coupling: The degree of dependency between two modules. We always want low coupling.

Cohesion: The measure of how strongly-related is the set of functions performed by a module. We always want high cohesion.

All methodologies try to reduce coupling and increase cohesion. Information Hiding reduces coupling by isolating the details of the implementation of state. ADTs reduce coupling by defining clear and abstract interfaces. An ADT that specifies in a single definition the set of functions that can be executed on a type is certainly more cohesive than a global data structure that is modified by external functions.

OOP adds another step in the reduction of coupling with the enforcement of encapsulation and the introduction of dynamic binding and polymorphism. Inheritance allows us to increase cohesion by defining hierarchies based on generalization and specialization, in which we can separate the functionality that belongs to the superclass from its subclasses. AOP provides a solution for the problem of cross-cutting concerns, so that both the aspects and the affected methods may become more cohesive.

There are many benefits that software developers expect to obtain when making a system more modular, reducing coupling and increasing cohesion:

Maintainability: A measure of how easy it is to maintain the system. As a consequence of low coupling, there is a reduced probability that a change in one module will be propagated to other modules. As a consequence of high cohesion, there is an increased probability that a change in the system requirements will affect only a small number of modules.

Extensibility: A measure of how easily the system can be extended with new functionality. As a consequence of low coupling, it should be easier to introduce new modules, for example a new implementation for an existing interface. As a consequence of high cohesion, it should be easier to implement new modules without being concerned with aspects that are not directly related to their functionality.

Reusability: A measure of how easy it is to reuse a module in a different system. As a consequence of low coupling, it should be easier to reuse a module that was implemented in the past for a previous system, because that module should be less dependent on the rest of the system. Accordingly, it should be easier to reuse the modules of the current system in new future systems. As a consequence of high cohesion, the functionality provided by a module should be well-defined and complete, making it more useful as a reusable component.

As software developers, after we recognize the importance of SoC, we need to apply this principle in at least two ways: Understanding the power of our programming language tools and patterns, and learning how to evaluate and compare different designs in terms of coupling and cohesion.

Tools: For each mechanism in the programming languages we use, we should understand how it can be applied to reduce coupling and increase cohesion. For example: How encapsulation, dynamic binding, polymorphism and generic types can be used to separate concerns? Similarly, for each Design Pattern, we can analyze how it helps to make a system more modular.

Designs: When evaluating and comparing our own design alternatives, it is always useful to think in terms of coupling and cohesion. Sometimes a design seems to be more complex than others, but this may be a consequence of a better separation of concerns, with fewer dependencies between modules through the definition of additional layers. Another design may at first appear to have too many classes, but this may be an advantage if each class becomes more cohesive.

Producing effective software designs requires lots of experience, but principles such as the Separation of Concerns are essential to perform a great work. So reduce coupling, increase cohesion and good luck!

Written by youryblog

September 13, 2012 at 8:04 PM

HTML Editors for the Linux/Fedora

leave a comment » – discussion about it. They recommend:
1. Bluefish
2. Quanta

Written by youryblog

September 12, 2012 at 10:29 PM