Syntax and Semantic of Code

Assalamo-alykom,

A question that I always ask when interviewing candidates applying to software engineering posts goes as the following:

In some programming languages,  you can call static method using the name of the object or the name of the class alike, if you have this choice in your programming language will you call that method using class name or object name knowing that both are syntactically valid ?

Frequently I get answers like “it doesn’t matter”, and more than often I get a strong confirmation “I will use the class name” but then when I ask why, candidates start mumbling with extra-galactic languages!

Amr Noman and me during Sustainable Refactoring workshop

What I am expecting as an answer, although I don’t often get it, is: yes, I will use class name because otherwise I will obscure the fact that the method is actually static!

The mere action of using object name, although  syntactically possible, has undermined the readability and impaired the semantic of the code.

In my not very humble opinion, writing code is no different than writing a novel or a poem, in all these good writing style goals of clarity, simplicity and creativity are due.

Earlier this year, I have invited Amr Noman form Agile Academy to run a workshop for
my team about “Sustainable Refactoring”. Amr was discussing different refactoring techniques like method extraction when he said “Your code should be a read as a story” I couldn’t agree more!

How you choose your methods and classes’ names, how each method name is consistently or inconsistently named, whether your code is extracted into a number of reusable methods or you are just copying and pasting codes everywhere and whether your sequence of method calls can be read in a natural flow that conveys what this code is doing,  this is what adds meaning to your code beyond the basic syntax.

Salam for now,

Advertisements

A Bird’s Wing

In their seminal work “Documenting Software Architectures: Views and Beyond” Paul Clements and the rest of the authors chose a bird’s wing picture for their book cover, and they beautifully describe how they use the bird’s wing physiological system as a new and rich metaphor for software and system architectures.

The authors in an introduction brief meant to convey the purpose and attract readers, draw a comparison between a Holism and a Reductionism approaches to describing complex systems such as systems that intensively rely on software components.

I chose to quote rather long passages from this book’s introduction here, I hope authors won’t mind.

They start asking “How would you “document” a bird’s wing for someone who did not know what it was?”

And then continue answering “A bird’s wing, like a software system, can be shown by emphasizing any of a number of structures—feathers, skeleton, circulatory system, musculature”

Here they decide that software system can be looked at from different viewpoints, which is a standard reductionist approach to comprehend any complex system.

Bird’s Wing for Renaissance artist Albrecht Durer (1471-1528)

In Paul’s and his colleagues opinion the dynamic attributes of the Wing system is what makes it unique, I would even go and say that they think that dynamic quality attributes are superior and more architecture critical than static quality attributes.

They say “The wing exhibits strong quality attributes: lightness in weight, aerodynamic sophistication, outstanding thermal protection. The wing’s reliability, cycling through millions of beats, is unparalleled. Unlike a house, which mostly just sits there, the essence of a wing is in its dynamic behavior. In coarse terms, the wing extends, flaps, and retracts; in finer terms, the bird commands movements almost too subtle to see, controlling pitch, roll, and yaw with exquisite finesse.”

At the end of this amazing piece they chose to introduce their book, they turn into admiring the whole system, where the total of the system is actually more than mechanical sum of the parts.

They say” For millennia, humans have tried to comprehend the wing by examining its parts and from different points of view. But the whole wing is much more than the sum of its elements and structures: It is in the whole that beauty and grace emerge. Mankind’s technology still cannot replicate the wing’s exquisite abilities. The common starling, a merely average flier, can slip through the air at 21 body lengths per second. That’s about what the world’s fastest aircraft—at 2,000 miles per hour—is able to manage.
Structure, substructure, replication with variation, behavior, quality attributes, and emergent properties of the entire system: All these aspects are important to capture when documenting a software architecture.”

Finally they pose a question, it is true that we have our humble trials to capture and understand a complex and beautiful creation of Allah but our tools are far limited from being able to describe its beauty and grace!

They say” We haven’t learned how to document beauty and grace yet, but for that we substitute the documentation of rationale, or what the designer had in mind. For software, we can do this. For the wing of a bird, we can only admire the result.”

Always moved by these last lines, the best book introduction I have read ever!
Salam

Nexus Guide, the Arabic Translation

Early last week, I had the chance to complete an Arabic Translation for Nexus Guide.

Nexus is presented by Ken Schwaber as “the exoskeleton of scaled scrum.”

In Nexus, Scrum is used as the main building block however the focus in Nexus is on integration of work products from different participants to form an integrated product increment at least each sprint.

This would enable Scrum to scale well for large teams handling complex projects.

In this translation, and for consistency, I made sure to stick to the same Arabic translation for Scrum terminologies from my prior translation for Scrum Guide.

Feel free to send me your comments, suggestions or corrections.

The full set of translations along with the original English version of Nexus Guide can be found on this page.

Salam,

Writing About AngularJS: 237 downloads!

We are now over 10,000 words and almost 80 pages into our book about developing an Enterprise Application frontend in Angular!

Being loyal to Lean principles, we didn’t have much planning in advance, we planned the first two or three articles/tips and we started experimenting with the writing process.. As of today, we have 237 downloads which is better than what we expected!

We are planning the coming chunk of tips, we think that we may need to rearrange the book content in a way that tips build on each other so readers can start from first tip and continue reading.

We also think that we may cover all the materials we want to cover in around 30-40 articles, so at some point the title “101 AngularJS Tips and Tricks” might need to be refactored!

Salam,

Yaser

Writing about AngularJS

There is a famous quote by Reid Hoffman, the founder of LinkedIn, that says: If you are not embarrassed by the first version of your product, you’ve launched too late. 

I guess I am not too late then 🙂

Allow me here to present my latest writing experiment!

https://leanpub.com/101-ng-tnt

101 AngularJS Tips and Tricks! is humble try to share the experience we gained, I and my team, while working with this fantastic JavaScript framework.

So, even if JavaScript or Angular does not interest you, I will be glad if you download this Early version of the book, but if either one does, then I will be grateful if you try some of the content and share with me what do you think, any suggestions, corrections, or recommendation are absolutely welcome!

Salam,

Yaser

Publishing as a Scientific Experiment

Lean thinking started in manufacturing in Japan around a core  idea of eliminating the “MUDA” or “Waste”! Any Lean leader will tell you: Don’t think if you can do something but rather if you should do it at all ? and hence focusing on value adding activities only.

From manufacturing, Lean Thinking spared to all domains, two interesting examples are software development thanks to the effort of Mary Poppendieck, and Lean Startup for developing businesses which is becoming a worldwide movement since presented by the work of Eric Ries.

Interestingly enough, Lean Thinking appeals to business leaders, software engineers and entrepreneurs alike because of how it handles uncertainty by the means of scientific experimentation.

Say you have this crazy idea of a new product that you think will change the world! we are all that person, aren’t we ? But think for a minute, can you really know for sure if your ideas will succeed or not ? You actually can’t! No matter how hard you plan, the odds that you will fail are very high!

So what to do then?

Actually you do nothing! Well not really nothing, you probably need to build only the product box or just design the product flyer then reach for potential customers feedback and use this feedback to plan and shape the next minimal product and so on, every time, you are actually experimenting with your idea based on the available information you have at the moment and some hypothesis of what will be attractive to your customers until you find what would really work!

Recently, I also discovered leanpub.com and it seems that lean thinking is applicable to publishing as well!  Leanpub.com is an innovative platform that provides tools to write books, publish them and solicit readers feedback to clear the path where the writing process should follow.

Although lean publishing and leanpub.com have their share of criticism, I and couple of my colleagues decided to give it a try, so in a next blog post I am sharing with you our first publishing experiment!

salam for now,

Requirements: Defining The Terms

It is important for anyone taking the responsibility of requirements development to set a communication framework in order to organize and facilitate requirement gathering, classification, documentation and dissemination job.

This framework should include a communication plan, set of templates, set of textual and graphical models…etc.

It may sound self-evident, but I often find it necessary to start this effort by first agreeing with stakeholders on the definitions of terms we will use in describing requirements. I frequently find this basic step necessary due to the disparate professional and educational backgrounds of project team members, also because of the overloaded terminologies we use when we talk about requirements.

To reach this common understanding, I usually start the analysis meetings by presenting the terms from reference sources such as Karl Wiegers books and discuss them with the team to come up with agreed on definitions.

From the last time I did this exercise  the stakeholders group discussed the following set of terms : Scope, Constraint, Assumption, Acceptance Criteria, Business Requirements, User Requirements, Project Requirement, Functional/Non-Functional Requirement , Feature, Use Cases, Actor, Metadata, Scenario, User Story, Business Process, Business Rules, SMART Requirement, Activity Diagram, Interaction Diagram, BPMN, Context Diagram, Entity Relation Diagram, Priority, MoSCoW Requirements, Artifact and Deliverable.

Discussing and agreeing on the meaning of such terms and other terms specific to the business domain will lay the groundwork required for streamlined and productive requirements development engagement.