Spell Corrector
I wrote a language agnostic spell corrector that uses Bayes’ Algorithm and BK tree. The application is a C# class library in 142 lines of code. The application uses DB4O as a database.
I hope you find the application and the source code useful.
Performance Benefits of Dynamic Compilation
Dynamic compilation is the process of compiling code at runtime. This code could be an intermediate language code or could even be a binary code that is re-optimized at runtime. Dynamic compilation of intermediate code is the technique used in compiling java and .net code.
In this article I will discuss the performance benefits of dynamic compilation in general with some focusing on dynamic compilation on the .net platform. Read more
Reddit and Filtering by Design
Reddit is a social news website, where a user posts links to pages on the internet, and then other users up vote or down vote this link. The links are organized Based on the votes and the time since the link was posted.
I have been a user for Reddit for more than a year now. The idea is not totally new, Digg already has the same idea, but the content on Reddit is much better than Digg. Digg is full with (cool stuff), links to topics and pages that tend to be nice, funny, weird, things that could appeal to the masses, but Reddit is much more serious and useful, and the links tend to appeal to the more cultured or intelligent reader. Of course the number of Reddit users is less than that of Digg. Read more
عن المبرمج نتحدث – 3
المبرمج يولد مبرمجاً
هل هناك فارق بين الناس في مدي قابليتهم لتعلم البرمجة؟ هل هناك أشخاص لا يمكن تعليمهم البرمجة أم أن أي شخص يمكنه أن يكون مبرمجاً؟ بعبارة أخري، هل يولد المبرمج مبرمجاً أم أن المبرمج يمكن صناعته بالتعليم و الممارسة؟
هذه التساؤلات هي نقطة خلافية كبيرة بين عدد كبير من المهتمين بصناعة البرمجيات عموماً. هناك فريق من الناس يري أن المبرمج يولد مبرمجاً. هو شخص لديه القدرة علي فهم علم البرمجة بسرعة و عادة ما تكون كفاؤته أعلي بكثير من كفاءة زملاؤه بسبب إستعداده الشخصي، و فريق آخر يري أن الموضوع متعلق بالتعليم، و أن الفارق بين مبرمج و آخر هو فارق في الكيفية التي تعلم بها البرمجة، و أن أي شخص يمكن أن يكون مبرمجاً إن مر بعملية تعليمية سليمة. Read more
عن المبرمج نتحدث – 2
2 – شخصية المبرمج
بما أن المبرمج هو العامل الرئيسي في نجاح أو فشل المشروع، و بما أن البرمجة هي نتاج عقلية المبرمج الذي قد يختلف بناء علي حالته النفسية و العقلية من يوم لآخر، و بما أن البرمجة عمل جماعي يؤثر فيه المبرمج و كيفية تعامله مع زملاؤه كان من الضروري دراسة شخصية المبرمج، كيف يفكر، ما الذي يثير حماسه، ما الذي يحبطه، ما هي المشاكل التي تواجه المدير عند تعامله مع المبرمج، ما العوامل التي يمكن أن تؤثر علي إنتاجية المبرمج و جودة الكود الذي يكتبه، الخ. Read more
عن المبرمج نتحدث – 1
تتميز صناعة البرمجيات بأنها صناعة تعتمد في المقام الأول علي المبرمجين. ليس هناك آلآت أو مواد خام أو تكاليف شحن أو أي عامل من العوامل التي تقوم عليها باقي الصناعات، فقط المبرمج. من هنا كانت تكلفة المشروع هي في المقام الأول أجر العاملين في المشروع (رواتبهم الشهرية) ، و بالتالي إن أمكنك تقدير الوقت المتوقع للمشروع بدقة أمكنك أن تقيم تكلفة المشروع أيضاً.
من هنا تأتي الأهمية الكبيرة للمبرمج في صناعة البرمجيات، و هي أهمية بالطبع تفوق أهمية العاملين في أي صناعة أخري. أي برنامج هو نتاج عقل المبرمج بشكل رئيسي، و بالتالي فإن المبرمج هو أهم العوامل التي يتوقف عليها نجاح المشروع من فشله. Read more
Test Driven Architecture
In the latest issue of the Architecture journal, Mario Cardinal wrote an article called Test Driven Infrastructures in which he discussed the idea of test driven architecture. He said that it is a good way of documenting the code, avoiding regression bugs and making sure that the developers are sticking to the requirements and the design.
I think of test driven development to be something that makes sure that you reach the end goal without checking the way you get there. See the following example situation:
I am designing an application that gets some data from the database and display them for the user. I choose to use N-Tier architecture with 3 tiers, one for the database, one for the data access layer and one for displaying the data to the user. If I put a unit test for the use case of the user requesting the data to be retrieved and displayed, how can I test that the developer is sticking to the 3-Tier design that I have made? How can I make sure that he is not writing code in the presentation layer that connects directly to the database?
This is something that was not mentioned by Mario Cardinal in his article but was mentioned by Peter Provost in his short video about test driven design. He said that test driven design is used to test methods and classes, not the higher level architecture, and I think that the same principle of “testing the goal not the way to the goal” applies even to small methods and classes. If I put a design that included a method that takes an array and sorts it, and I said that I need the sorting to be done using x algorithm (for the sake of performance or memory usage or any other reason), how can I put a unit test that makes sure that the developer implemented it in the same algorithm that I explained to him?
Another difficulty in test driven development is creating the tests by someone who is not a tester (the software architect). Design, development and testing are three different jobs that require different skills. A good developer or designer is not a good tester necessarily. See this blog for a discussion for the idea.
Of course there are benefits for test driven development or design, such as avoiding regression bugs and a good way for documenting the design (when combined with other design document and diagrams, not alone).
No silver bullet, the old immortal rule for software development. If you want to use Test driven development for its benefits, you should make sure that your unit tests are not the only tests you are using. Use also other testing techniques (for example peer review) to cover the holes left by your unit tests.
Construx Software Starts New Forums and Blogs
Construx Software, the software consultancy company of Steve McConnell -Author of Code Complete and Rapid Development- has started new forums dedicated for discussion of software best practices in management, requirements, Design, methods, etc. Steve McConnell is a member in this forum and shares in the discussions.
Also the company has started a series of blogs by a number of technology experts including McConnell himself.
The forums and the blogs are here.
Testing Programming Ability
In an excellent article, Irman has brought out the idea that measuring programming knowledge is different from measuring programming ability. Most programmers’ interview questions are questions that test programming knowledge only. The problem is that measuring programming ability is not easy. Since programming is mainly a mental work, when we try to measure the programming ability of a developer we are trying to measure one of his mental abilities which is difficult.
One of my job responsibilities is interviewing new developers and evaluating them technically. I have thought of the idea of testing the programming ability and I have found that asking controversial answerless questions is a good way of measuring a developer’s mentality and attitude.
For example when I interview a developer who says that he had worked on multiple database management systems, I ask him which one he thinks the best one. Of course this is a point that has no general agreement, and the ideal answer is to ask: better for which application? Or Better from which point of comparison (price, cross platform support, performance, etc). The way a developer answers such questions is a good indicator to his experience and the way he thinks as a developer. Once I got an answer form one developer that DBMS X is better than Y because the interface of the management application of X is better than the interface of the management application of Y!
Another point to ask about is performance problems. I generally ask this question: “We had built a web application that does bla bla bla, and when publishing the application, we found that its performance is bad when the load is heavy. Where could be the problem that is causing this bad performance?”
Of course the answer is to profile the application in some sort or another to know where is the problem exactly or to think of testing some parts in the application before the other based on some data or facts, but most low level developers give single clue less answers such as: “There could be someone who opened a connection to the database and didn’t close it, or we should not use joins in the SQL queries” or any similar answer.
Anyone who answers these answerless questions in the “good way” – I am not saying the right way because there is no right answer- is most probably a good developer. The problem is that very few people answer these questions in the good way.
Another point is asking about the details. Most low level developers just write code without knowing what is going behind. For example, I found that most low level .NET developers don’t know when an object is candidate for deleting by the garbage collector. He just writes code and his mission ends when the code works, without bothering much with the details behind. I am not talking here about very low level details, just slightly knowing what is going behind. Till now I hadn’t interviewed a developer who knows what the term generational garbage collection means. If I found him it would be a memorable day for me!
I know that in the software industry more than half the developers are less than average- the normal distribution curve doesn’t apply in this field unfortunately- but here in Egypt the situation is much worse than what is in America or Europe. In some way or another you are obliged to accept low level developers to put them in limited specified roles or get novice good minded developers who could be good developers with time and mentoring from senior ones, which is more difficult.
Also having a test period before signing the contract is an excellent back door to escape from a bad developer. You cannot be 100% sure that a developer is good or bad based on the interview only. Also some things are still immeasurable such as interaction with team members and moral qualities, and the only way to measure them is in the work field.
Them vs. Us: A Developers’ View Point
One of the problems with development is the separation between managers and developers. In many cases, Project managers or software development managers are viewed by developers as the other people (them). This separation has many possible reasons:
- Managers don’t listen:
A lot of managers do nothing but just give orders. They need this list of features to be done in x days from now, although developers say that this is impossible (due to technical reasons or because the given time is not enough). This is a killer mistake.A study done by IBM showed that the developers’ estimates are much more precise than that of their managers. The one who will write the code is the one who decides whether it is possible to write it or not in the given circumstances. Steve McConnell says that a manager discussing his developers’ time estimate is like someone discussing why a kilometer contains 1000 meters.
Managers who don’t listen are morale killers. Anyone can have a moment where he needs to be listened to. Listening is an important communication skill – see the 7 habits of highly effective people. A manager who doesn’t listen decreases the productivity of his developers significantly, and in turn affects his project schedule negatively.
- Managers separate themselves in a higher class than developers:
Some managers think of themselves as the masters, the other developers are the rabble. They don’t share time, opinions or conversations with those who are lower than them in the functional ladder. Here is an interesting story was told to me by a friend developer:This friend was a junior developer on a web project. The senior developer wrote a page that does some stuff and shows the user some confirmation and error messages based on what he is doing. My friend said that he thinks one of the messages is not very user friendly. This was all what he said. The senior developer became very angry and shouted and went to the software department’s manager and kept yelling and shouting that “This is a junior developer and I am the senior, how come that he criticizes my work?” - Developers put themselves in a lower class than managers:
Sometimes the manager is willing to hear ideas and discuss things with his developers but some developers think that managers’ thoughts are above discussions. All what a developer has to do is to implement what his managers’ want without thinking at all.
One of the ways to solve the “Them vs. us” situation is to use someone in the middle between the developers and the managers. For example the software architect is someone who deals with the managers and also deals with the developers. I don’t mean the software architect in particular but anyone who is in the middle between management and development depending on the development style and life cycle model. Some development paradigms don’t even define a role for the software architect.
This “man in the middle” can transfer the thoughts of the developers to the managers and transfer thoughts of the mangers to the developers- specially in teams with big number of developers and managers where hearing every developer could be a burden for the managers. The “man in the middle” could understand the ideas and thoughts of managers and developers, and both teams are willing to listen to him. If the managers are unwilling to listen to developers he can explain how important this is, and how this could affect the project.
In some situations, the “man in the middle” can ask for a meeting between the developers and the managers when he senses that there is something that needs to be discussed without a mediator.
Of course the “man in the middle” idea can only one work in an environment where mangers are willing to listen to developers. If a manager insists on being “Mr. knows everything” then no idea is going to work with him.
keep looking »