Partitioning: Design Phase

I think I will sound a little negative towards partitioning in general. For something that seems simple to implement in a weekend like Tetris, it's going to take us three weeks to finish here. Let alone all the problems that will result from the lack of co-ordination between the different team, and the assumptions that each team will make about the other teams.

The hardest thing in the design phase was to figure out how should each piece or component of the program connect with the other, defining the APIs needed, and making sure that each component gets exactly what it is expecting.

That was all the talk this week was all about, and theoretically everything is setup and ready for phase 2, the implementation! I'm going to sound negative again, but more problems will show up I think, things that we didn't anticipate in our design. Hopefully that won't be the case, but wishful thinking isn't enough. We will need to communicate more during the implementation phase, and will need to adapt the design quickly to any needed changes. If it's just going to be that each team implements its own part and that's it, it's going to end up in a disaster.

More spices will be added to these problems if you take this project to a global development level. All problems will be amplified and magnified. I keep asking myself this question, with all of the problems and risks associated with global development, why would we go for it? Overall, it doesn't even seem cheaper at all.

I started reading in the “Smart Sourcing” book, which was talking about how necessary it is to outsource some work to help the company focus only on its major competencies, the things that it is really good at. But is that really worth all of this risk? I guess I will find out more as I continue reading the book.

Subordinate Projects : I Got the Point

With part 2 of the project successfully completed, now it's time to reflect for a while. The whole idea of subordinate projects is to save time of both the designer team and the implementation team, by making each team focus only on one thing at a time, and creating parallelism in their tasks.

After this assignment project, I tend to believe that this is not the case at all, and probably in a real world situation it will be even worse. It does NOT save time.

For the designer team, it takes time to:

• write a good TDD,
• explain it to the implementers,
• make sure they understand everything, 
• follow up their progress to make sure they are on track,
• test their code and report their bugs,

And for the implementation team, it takes time to:

• understand the design,
• request changes to the design,
• understand difficult algorithms that the design might be dependent on,
• work on the bugs resulting from your lack of understanding of the design,
• defeat your "ego" or "selfish" feeling that you could have designed it better.

 Add to the above points that both teams are from two different cultures, speaking two different languages, possibly in very different time zones, and with different education backgrounds, add these and there is a huge potential for disaster I believe. It will be even less efficient and less profitable.

I have to mention here though, that if both teams, the designers and the implementers, were the same team or at least co-located, this could achieve the desired purpose of having a subordinate project (the efficiency and parallelism). This will make dealing with the above problems much easier and less time-consuming.

Project 2: Designing for Others to Implement

First of all, I want to mention that I really love data structures. The 'Data Structures And Algorithms' class, which I took in the summer quarter here at DePaul University, changed how I think so much. Now I always analyze any code I write in the back of my mind. Asking myself questions as:

• Is it efficient enough?
• Is this the best way to store the data?
• What are the operations that I will need to do quite often on these data? Maybe I can focus on optimizing those more?

It was a fun and challenging course that I really enjoyed. Yet, I'm quite sure that there's still so much to learn. There's no single class that will give you everything. There're people who spent years and years of research to come up with maybe slightly better solutions than existing ones for certain problems. I believe that as much as this field is a science, it is also an art and an intelligence.

Now back to the 'Search List' data structure that we had to design for this project, so that another team in the class will implement it. Everybody, gave it a bit of thought, and came up with his own idea. I spent a whole night working on it to present my idea to the team during our Skype meeting that we arranged the next day.

My design idea to implement it as a binary search tree was welcomed by the other guys, and they thought it was the best approach. Now it was my responsibility to write the design document for the other team. Everyone thought that I would come up with a single-page document that has some general design decisions that I made. Well, that's not how I think! Whenever I'm assigned a task, I believe I'm 100% responsible for it and I must be fully committed to produce the best output that I can. For me, and that's something I learned from my previous work as a Telecom Engineer, being a team member means lifting your team up on your shoulder if you can. It's not like just do your part and that's it. It's more like do your part and help others do theirs as well. It's exhausting sometimes I have to say, but it's very rewarding when you see your team appreciates you and the team itself is prospering. This is what I came up with:

They were surprised that I wrote a 5-page well-formatted design document, with examples, sample code, diagrams and UML. I felt really happy that they liked it.

I also took the challenge of implementing my design just as a coding exercise. I wrote the whole data structure in Java, and then tested it, and it worked. Well, we're using C# for this class, and I could have definitely written it in C#, but here's why I wrote it in Java:

• While C# and Java are quite similar, I haven't used Java for a while, so I thought this is a good time to practice a bit.
• I love Eclipse, more than Visual Studio.

There's something disappointing though. While we all thought that this was the best easiest approach, the professor told us yesterday that he has a better and an easier solution for this data structure than the complex binary search tree, and he will show it to us next week. I can hardly wait!! It is very interesting and very exciting to know how much I still need to learn.  I really believe in this saying: "The more you learn, the more you discover how less you used to know". This is absolutely true! And above anyone endowed with some knowledge, another who knows more!

Back to the love of data structures, I really thank Mr. Keenan for forcing us to write our own whenever we need any. I'm sure we'll reap the rewards of this later on. I think I already started to reap some of these rewards now, by feeling so much comfortable with data structures. I also had to send a thank you e-mail to my data structures class teacher, Mr. Jonathan Gemmell, for being a great teacher. We have this saying in Egypt, "I'd become a servant for whoever teaches me a single letter!" That's why I felt grateful, and had to thank him. Here's what he said when he replied back to my e-mail:

"Thanks, but it's really not hard to teach a student as motivated as you.  Good luck in your degree!"

I'm really happy that I made the decision a year ago to come to DePaul University. So far, it's been a great place to learn.

Unit Testing: How Come I Never Used You Before?

Unit Testing is absolutely something new to me; I have never done before. But it has such a great power that I keep wondering how come I never used it before. It's true that I'm still relatively new to the software industry so I have my excuse. Honestly, I heard about it before several times, but I never cared to explore more about it since Testing is usually something regarded as something boring and unattractive.
Now that I had to try it for myself, I really realize its power now. I keep imagining myself writing some pieces of code and then writing their unit tests routines and make sure they all pass for all possible combinations of input and output. And then a while later, coming back to that same code to refactor it and probably add new features or implementing a new algorithm and so on. After I'm done, all I have to do is just run those tests that I already wrote long time ago, and make sure they still pass, if not, then I must have introduced some bugs or broke the code some how. This is really great to validate that new features doesn't introduce new bugs with them. Of course, some tests might need to be modified to accommodate some changes in the code. But generally, this is a great way to guarantee correctness of work.
There's this whole other idea of Test Driven Development (TDD), which I believe, well, is good, but it seems that it has the potential to waste time. I'm not sure of that though, since I've never had experience with it. But it's certainly a good way of validating code while being on the process of writing it.

With project 1 almost completed, I have to say it went smoothly without any problem. Everyone committed to the deadline they chose for themselves, although one team member had lagged behind a bit, but the good thing is, he confirmed that he's working on his tests, and is willing to finish them tonight.
What concerns me is that our team members are mostly busy, we don't get to stay in touch a lot. We didn't have to for this project because apparently it was mostly easy for everyone, but how is it going to be in a bigger project. I tend to think that we should take advantage of this opportunity to simulate as much as possible the real thing .. a distributed development environment. Yet again, everyone has different priorities, including me. I just want to be ready for the real thing after graduation. There's room to make mistakes now, but there won't be later. That's the opportunity I want to take.

Project #1: Will It Be A Success?

Now that the first phase of the project is over, which was supposed to layout our team's process and plan, I really feel concerned. We've been trying for a week to setup an appointment to Skype, we eventually managed to at the end. A lot of the decisions we needed to take were postponed until we managed to Skype, so I think we were a bit late.

It's understandable that everyone has different priorities. some team members are taking a lot of other classes, and some of them are actually working for long hours every week. This really simulates the real thing I guess, Since most companies will have different projects with different priorities. That made me wonder, how can we put everybody on the same wavelength? Is it done through strict due dates, or through being pushy to everyone?

The team lead position was not easy to decide as well. Everyone says "I can do it, but if someone else want it I'm fine with that". Everyone (including me!) is afraid to impose himself on others, which is a good thing of course. But still, someone had to step in anyway, and that's what happened in our case, someone just volunteered.

What concerns me is that it took a while to setup the basic things, how is it going to be when we actually start the real work and do the unit testings? I believe that everything is difficult at the beginning, and once the basic processes are laid out, everything else flows naturally afterwards. So hopefully it will be a success!