Friday, February 25, 2011

What should I learn in my CS degree?

My strongest believe is that everyone who devotes his life to Software Engineering, should have a CS degree.

Why? Well, it's a different question, so I would postpone my answer for now.
Instead, in the following post I would like to emphasize the subjects (and hence the tools) one should acquire during his studies.
These tools are essential in creating a "shared" language between us the engineers.
These tools are essential in being the solid ground of our day to day architectural and lingual abstractions.
These tools are essential in being the means of our research capabilities, logical deduction, advantages and disadvantages of each method we apply and etc...
In my opinion, those are the topics one should concentrate on:
  • Data Structures - Any course that involves Data Structures, from basic to more complex Data Structures.
  • Algorithms - Graph Algorithms, Dynamic Algorithms, Greeding Algorithms, Aproximate Algorithms, Computational Geometry and etc...
  • Operating Systems - Everything that involves Operating Systems from theory to practice. If there is a lab on OS, take it!
    The importance of understanding the bits and bytes of the biggest abstraction we work against every day is priceless.
  • Artifical Intelligence - Searching techniques, Logic deduction, Decision tees, Learning technique such as Markov Chains, Neural Networks, Bayesian Networks and etc...
  • Programming Languages - No, it isn't "Programming in Java"; These courses involve the principles of Software Languages, which are crucial for identifying the right tools for the job.
    Imperative and Declarative Languages; OOP, AOP, Functional and Logical Languages; The more principles you learn (and the more languages you see) the more you will understand how to apply these languages and when.
In addition, I recommend taking a few "narrowing" courses, courses that are deepening your expertise in a specific field.
Some examples are: Natural Language Processing, Computer Vision or Distribute Programming.
It's worth noting that, in my opinion, practical principles of "constructing" software should be learned differently.
Those skills are better acquired by enrolling into an apprenticeship program, by reading classical books and essays, by rubbing elbows with others or by deliberately practicing.
If you are interested in such practical experience, please apply for the Mentorship/Apprenticeship program we enrolled in our Software Craftsmanship Group.

Thursday, February 24, 2011

One small step for a man, one giant leap for mankind

(Cross post from IRefactor)
Lately I had a lot of thoughts about how to introduce a change within an organization.
For a while now I am giving some talks about leading a software development team, focusing each time on a different facet, such as: Quality, Architecture, Recruitment Process and etc...
(I have combined some of those thoughts into a short lecture, which I entitled Fostering Software Craftsmanship (Building Successful Teams) and it is given as a part of the IL Tech Talks).
But here is a phenomena, I encounter each time.
Most of the audience understand the importance of the concepts, but really struggle with introducing them to their organization.

Martin Deutsch
  • Writing Unit Tests will lengthen my development time!
  • How much time should I "reserve" for doing Refactoring?
  • How do I explain to my manager that Refactoring is important?
  • Code Reviews are difficult, because people have different tastes!
  • Code Reviews are taking too long! We will not be given the time to do it, ever!
  • Continuous Integration will take a few weeks to accomplish. I won't be given any time to do it in the near feature!
  • Those concepts are great, but the time to do them should be allocated by the management.
  • ...
I am sure we all heard those sayings. Heck, we even have given those once! (No... Not really :) )
Though I have a lot to say and comment about each and every one of the above statements - there are some broader aspects I must cover first.
We all hate changes, don't we? Doing Unit Tests, investing our time in Refactoring (or Builds) - those are just an extra activities that we have never done (or done correctly).
One should really invest his own time in order to polish those activities and doing so is just recognizing that we need to change. As humans, we find it extremely difficult to accept changes.
Jack Welch understood it perfectly, but nevertheless he succeeded to introduce a lot of changes to GE. Jack Welch found the change to be exciting, daring and imaginative.
GE success can be rooted to its ability to change and to change fast.
However, applying change in the simplest way doesn't work.
We cannot accept the change all at once. Evolution takes its time; Therefore, in order to accept the change we also should adapt one step after another.
(It's really like Refactoring Steps: One small change at a time, compile and test).
Sometimes it takes years to introduce all those concepts to your teams:
Start by a simple task, like code conventions or source control layout, then teach unit tests and invest in teaching code smells, continue by applying rigorCode Reviews and etc... and etc...
Doing everything in one big bang just doesn't work. I have seen several teams that got introduced to Scrum or TDD in a matter of weeks. Those are big changes to somebody who didn't evolve to the "right" point. Needless to say that the failures that those teams experienced were so discouraging that till now some of those Software Engineers hate TDD and claim that Unit Tests (even not TDD) are plain waste of their time.
You shouldn't be surprised that applying all the great concepts to your organization will take years.
One step after another; One small step for a Software Engineer, one giant leap for an Organization.

Close-up of Astronaut?s Foot on Lunar Surface - NASA Images

Seventh Software Craftsmanship Meeting

I am very excited to announce the 7th SCISR meetup.

How to utilize efficiently Programming Languages?


-Dynamic languages seem to be more concise and less verbose than their Static counterparts.

However, using Dynamic languages efficiently requires a different approach.

During the first part of our meeting Reuven Lerner will demonstrate the
differences between Dynamic and Static languages and present the right approaches to utilize the full power of a Dynamic language.

-While general purpose languages can solve any problem, the creation of special-purpose languages for expressing problems and solving a particular problem domain is highly efficient.

During the second part of our meeting Dror Helper will explain and demonstrate what are Domain Specific Languages (DSLs) and how they can be used to solve problems in a particular domain.

Hands On:

In the hands on part we will exercise writing DSLs.

Please bring your laptops (with the environments set-up) to the meeting.

Time frames:


18:00 - 18:25 - Gathering

18:25 - 18:30 - Short Intro

18:30 - 19:00- Static vs. Dynamic Languages

19:00 - 19:05- Break

19:05 - 19:35 - Domain Specific Languages (DSLs)

19:35 - 19:50 - Break + Giveaways

Hands On:

19:50 - 21:00- Implementing DSL


We have great giveaways to give during the meeting. DON'T miss them :)


Although we are plaining to have basic food, please also bring something with you for the group.

(Thus we will be able to support the event with the user generated food).

Please register here.

Software Craftsmanship - Meeting 6

Chronicles of the 6th Software Craftsmanship (SCISR) meetup.

This time, we discussed and practiced my own very beloved technique - called Refactoring.

During the session Itay Maman demonstrated a real life project that he needed to refactor for his company.

On the first part of our meeting, Itay refactored a very lengthy method in the CustomAction class, called actionPerformed.

Here is the initial code of that method.

You can watch the session here, where Itay demonstrated his approach and the refactoring steps he applied.

On the second part of the meeting, we practiced by refactoring the same code, but this time without the unit tests.

If you are familiar with Refactoring, then you should know that it is totally incorrect to perform it without the "safety net", i.e. unit tests.

However, Itay's genius idea, just proved to all of us that changing the code without having the confidence of "not breaking" the system (i.e. unit tests) is very hard and almost impossible.

As usual, I had a great fun. My hope that the community will continue to grow!