SourcePs: this is not what i write but from the author above which i put into the blog.
Below is 100% quoted from the source
Random ramblings of an obsolete programmer
No - I don't think that people are getting dumber as time progresses. But I do think that we are some how not helping the next generation of developers to improve up on what the people who went before them left behind. And this includes ABAP developers. When I say "we" - I specifically exclude the smart ones who didn't jump into the holes and avoided the temptations. So all the good and smart people - the stuff below is not about you, and don't get offended.
Some of you might know that I started my SAP career as an ABAP developer. I have no claims to have been in the league of Thomas Jung or Rich Heilman :) . But I believe I was an above-average programmer. As my career progressed, I moved on to other things - BW, SEM, SD, CRM and so on, but never did leave the "dark side". And I have been actively mentoring several consultants over the past years, many of whom have ABAP as their core skill. It is my discussions with my mentees that primarily prompted me to write this blog.
In my first SAP project - the server had 500 GB hard disk, and 1 GB RAM. This supported 25 users in a small manufacturng company. The desktops all had 32MB t0 64MB RAM, and something older than the pentium processor. This meant we had to think really hard about the code we created - anything inefficient would never get past the QA box. And we did not have a QA team - the developers could see for themselves when their code was terrible - and would go right back to re-designing the code. There was no code-inspector in the workbench either :) . Of course traces etc were available, and well utilized. Our team leads used to have competitions on who in their team would write the most efficient programs.
Most of us knew some other language before we learnt ABAP. And amongst my peer group at the time - the most common "first language" was C, and Dennis Ritchie was (and still is) God. One of the biggest gripes we had about ABAP was that it did not give us the flexibility that C gave (countless arguments about sort algorithms in C and then a simple SORT command in ABAP). This background in C ( the other popular one was LISP, which unfortunately I never got to learn), and the hardware limitations must have played a significant role in how our coding styles evolved.
ABAP programs mostly followed a procedural paradigm when I started. And then at some point, the OO paradigm started to kick in. By this time, I had started to lead ABAP teams. It was an awfully difficult time for developers to adapt - and people developed a hybrid style. If you had to maintain programs that were developed in this era - my sympathies are with you. Coincidentally, processors had become more powerful, and memory had become cheaper (though not as much as it is today). As a consequence - we had much more powerful servers and PCs, and as a result, we did not have to worry too much about algorithm efficiencies to get the same performance as before.
I did not realize the harm that had set on us, at the time - we just got habituated to write mediocre code. As moore's law kept proving itself as time progressed, we started going more and more backward in programming. The pathetic part is that we never realized this in time. Since we did not have to worry about quality to the extreme extent like before, we used the time to develop more and more programs and functionality. Dreadful as it might sound - quantity won over quality. We even slacked on peer reviews of code, that used to be second nature for us not that long ago. I believe that this also partly contributed to a decrease in the standard of training that new developers recieved. You no longer needed an internship to start your SAP career - a 6 week training course became a very acceptable entry criteria for developers.
Evidently, I was not the only team lead who realized this. And voila - SAP projects all over started having QA teams who started inspecting code formally. A lot of clients with big SAP footprint started having inhouse QA teams for it, and consulting companies started selling this as a service. I do believe that this helped some - things did get a bit better, but not for long. If you do anything en-masse, you have to standardize. And QA process became standardized too - and along with the good, came the bad. A lot of QA people I have come to know, barring a few exceptions, just go through a checklist mechanically, and do not take the time to understand the actual algorithm and offer meaningful suggestions. This is something a developer can do for his own code - and I am not sure if this type of QA really adds a lot of incrememental value.
I have been debating the solution for these issues for a while now - and here are some of the things we seem to get some consensus on.
1. Don't just train new crop of developers in just ABAP - also educate them in good software engineering practices. It might also be a good idea to train them in a second language if they don't know it by the time they learn ABAP. It is hard to improve when you have nothing to compare against :)
2. Have better benchmarks - somehow show the developer how much better his programs could be. ( A friend of mine, if he has his way, would like to have a QA box which is much less powerful than production for developers to get their code better).
3. Have a compulsory internship with a good senior developer, before some one is allowed to work independently as a developer.
4. Encourage senior developers to take turns and lead the QA teams, and don't let any one be in QA role for very long.
5. Encourage debates on programming practices - do not blindly follow something without getting a solid understanding of the arguments for and against. For example - Offlate, I have not seen many developers who argue against OO as a development paradigm. Infact, the prevailing sentiment is very much against the old procedural paradigms. However, I have heard and read several interesting conversations where people tore the OO paradigm to pieces. It is less important on which side of the debate you are positioned - the important part is to participate, and expand your thinking.
I have one other area that is close to my heart, that I wanted to bring up here - the maintainability of the code we develop. However, I guess I have over stayed the welcome for one web log, so I will defer that to another day.
So, what do you folks think?
No comments:
Post a Comment