Category: software

First, there was One Tier, and it was good. Back in the eighties, there was one mainframe and users’ dumb terminals were connecting this one and only Big Iron. These 3270 terminals were called dumb because they had only a keyboard and a monitor. No CPU. It was simply an I/O device.

Two Tiers. Thanks to Bill Gates, PC’s with their own CPUs came to masses, and in the end of 80th and early 90th I was developing Client-Server applications with fat clients ndash; part of the calculations was done locally and the data was sitting in the remote DBMS server. Life was simple. The resumes of the developers were simple too. You’d only need to know SQL to manipulate the data and some programming language. C++ would do. Too difficult to learn? Use SQLWindows, PowerBuilder, Visual Basic, or Delphi instead.

The main subject for discussions: where to put business logic ndash; in the fat client or in DBMS as a stored procedure. In the latter case you’d also had to master the procedural language of DBMS of your choice, e.g. T-SQL or PL/SQL. But that was it.

The architecture of the application was still simple. The ability to start the application didn’t require you to have an Internet connection, and this was good. The applications were launching locally. Sure enough, if the DBMS server was down or if too many users wanted the data, you couldn’t do much, but this was the only bottle neck back in the day.

Three Tiers. In mid-nineties, the creation of Web browsers made the Internet public. Enterprises were eagerly redesigning their tried-and-true client server systems just to put them on the Web. Why? Because they could. This is when things started to get complicated. A thin HTML client would talk to a Web server that either could serve the static content (texts, images) without asking for any third-party help or would need to pass the control to another server for smarter processing. Internet server providers were offering bandwidth for sale. Network connections were slow. The thin clients were poorly looking comparing to rich Visual Basic or PowerBuider UI.

The question remained the same though, “Where to put the business logic?” The thin client was out. Now the choices were either somewhere around the Web server or in DBMS. Just having the Web server was not good enough. Since I’m from the Java crowd, I’ll explain you what was going on there.

Multiple Tiers. The middle tier turned into multiple tiers. A Web server talks to a Servlet Container, which in turn talks to an EJB container, which either talks to the DBMS directly or simply places the message into a queue provided by some Message-Oriented Middleware vendor. To make this even more flexible, add to the mix some Naming and Directory servers so the Java tier will perform a lookup of the queue first and only after that will publish a message there. Let’s not forget about demilitarized zones, which will increase the total number of tiers.

This is when the new breed of developers was formed. These people were calling themselves Application Architects. They demanded more application-specific logical layers. And they wanted them now! The book on design patterns by the Gang of Four was made readily available and the Witches’ Sabbath began. Software frameworks flourished.

If a Java developer didn’t know Struts framework in the beginning of the century, his/her chances of being hired for enterprise development were close to zero. Now more and more people understand that Struts was yet another over-engineered useless MVC framework that overcomplicated the architecture of thousands of applications. But the very existence of such frameworks received the warm welcome or even standing ovation by legions of code monkeys who realized that they can make a living by inserting limited-liability-if-statements in the templates, prescribed by local architects. Pursuing Computer Science degree is not needed any longer.

The first decade of 21st century is coming to an end, and we still live in a very fragile software dozen-tiered software world. Every additional tier (a.k.a. moving part) makes the architecture even more fragile. Every moving part is being purchased with an extra expense ndash; technical support. But in the muddy waters of multi-tier architectures, the tech. support teams pretty quickly start playing the game of pointing fingers.

The budget initially allocated for the project, gets drained rather quickly, the project owner starts cutting corners, which leaves him with a somewhat working applications. It’s great that our offshore partners are ready to extend a helping hand! We need it. It’s like money from home.

Two Tiers. In two weeks, the second decade of the 21st century begins. I really hope that we are going back to two tiers again. How so? A tablet talking to a cloud makes two tiers. You can argue that the cloud itself has tiers inside, but this is different though. It can be maintained by a single vendor, and from the client “s perspective it’s one piece of software.

The client’s application is started locally from a tablet, it has a local storage that enables work in the occasionally-connected scenarios. Both the data and the code are brought as close to the user as possible. Why do you think Microsoft Excel is the most popular software among business users in the enterprises? Because it allows a user to have her own little piece of data and amateurish-but-working-code (formulas) very close and personal. Right on the desktop. No need to ask these IT prima donnas for favors. No dependencies on the connectivity or some mysterious servers being slow or down. The most advanced business users even learn how to operate MS Access database to even lessen the dependency from IT. Way to go!

Consider sales force automation. Our company works now on a solution for the insurance application that automates the work of agents. I’ll just give you one example. We store digital signatures of the clients in the database. The agent comes to the house of the customer, fills out the electronic forms and asks the person to sign with his/her finger right on the glass of the Android phone. Adobe AIR applications saves this digitized signature in the local database right on the phone. As soon as the agent can get on any WiFi network, he can synchronize the local data with either PC or a cloud. Isn’t it two tiers? The sales person can start and run their application without depending on the availability of the Internet. When connection is available, the data gets synchronized with the Tier 2. This is it. Client-Server is back.

One Tier. The chances are pretty high that 10-15 years from now we’ll downgrade the architecture back to one tier turning our smart phones into the dumb ones.

“You can say I’m a dreamer. But I “m not the only one. ”
John Lennon

In the mid nineties, IT job market was good. PowerBuilder or Visual Basic plus SQL would get you employed in no time. Good old client/server days hellip; Lots of mainframe programmers were easily surviving knowing nothing but Cobol and SQL (DB2). Two programming languages was all you need.

When multi-tier architecture became hot and J2EE came into picture, all of a sudden you’d have to learn a lot more languages and technologies, for example, Java, SQL, HTML, JavaScript, XML, JSP, EJB, JMS etc. And I’ve learned all this jazz.

Five years ago the IT job market was really bad. Five years ago job postings would require knowledge of ten different programming languages, and if you knew only nine, you could not get a job interview let alone job. At the time I’ve been working as an independent contractor, but the job market was so bad that I couldn’t find a decent contract and became a full time employee of a major bank, where I spent about two years. On Fridays, I’d send out an email to everyone in our department with a little SQL puzzle. Some of them I’ve been inventing myself, some googled up but most of them I took from an excellent book by Joe Celko called “SQL for Smarties”. These emails were well received and people were responding with the answers written in SQL.

SQL was still in favor. Technical job interviews would include a couple of SQL questions. It’s hard to believe, but people knew how to find duplicates in a database table by manually writing “group by” and “having” clauses.

How many people have read the book by Joe Celko, “SQL for Smarties “? Let me put it another way. How many people had ever written any SQL statements? Why bother, an Object-Relational Mapping (ORM) framework like Hibernate will let me map Java class attributes to the database table columns. How nice…I ‘m drowning in XML now.

I never liked ORM. I trust SQL. Surprisingly, the young generation doesn’t mind being polyglot programmers as long as the set does not include SQL. The popularity of this language is comparable with the popularity of Latin and Esperanto in the real world. Why? I don’t get it. SQL is a very elegant and powerful language with an excellent ROI!

Note. In the next two paragraphs I’ll be bragging, so you might want to skip them.

In 1997, I was hired for a PowerBuilder/SQL job by a small company that was developing software for telecommunications giants like South Bell. On my first week on the project, Sarah, the co-owner of the firm was absent – she was about to deliver a baby. I had to wait for her as she was supposed to give me an assignment. Someone showed me a report written as a Sybase stored procedure. This daily report would run for an hour collecting various data about activities of the field technicians. This report was poorly written – it was using several cursors that were making multiple passes through the same data set. I’ve eliminated most of the cursors by re-writing the “where ” clause in the main SQL statement and applying some characteristic functions. The execution time of this report went down from an hour to under a minute. Everyone was impressed. I became a proven commodity and spent a year in this company enjoying an easy contract with high pay check till the company went belly up without paying me the final check. Talking about the power of SQL!

Here’s one more interesting detail. When Sarah came back from her short maternity leave, someone delivered the great news to her, “Yakov modified that slow report, and now it only takes a minute to run!” She looked at me and said, “Working with SQL was not your job, but I’m not angry with you n- I’m too long in this industry”. A couple of days later, I found out that Sarah was the original author of that stored procedure and my bad behavior showed here little weakness. Customer’s interests often have lower priority than a someone’s ego, but that’s another subject.

In one of my mid-nineties jobs I met a very good programmer named Roman D. who introduced me to characteristic functions in SQL (they were described in this book). These functions are not easy to grasp, but when you get it, your SQL will work a lot faster. Roman was a seasoned consultant, and he shared with me an important technique for passing technical job interviews. He “d explain characteristic functions to the interviewers, they were impressed and would extend him an offer. I said, “Roman, nobody knows about these characteristic functions, and the chances are less than slim that someone would ask you about them during the interview.” He smiled to me and said, “I do not wait till someone asks me about them. It’s my strong point, and I always find a way to change the subject and show these SQL tricks.” I “ve mentioned this interviewing technique in my e-book “Enterprise Software without the BS”.

May be one day the ORM tools will generate highly-optimized SQL, but it won’t happen any time soon, that’s for sure. Proponents of ORM tools would argue that their tools also allow manually write SQL statements in one of their XML configuration files. If this is the case, and if you are capable of writing SQL, why bother with ORM to begin with?

Let me tell you an old Jewish tale. I’ve used it already in a couple of my other articles before, but it’s applicable in so many life situations including computer programming…

A poor man comes to the rabbi complaining that his family has only one small room, many kids, and almost no money. The rabbi says, “Take all your money, buy a goat, and keep the goat in your room. Come back in a month. ”

“But, rabbi, we don’t have enough space even for us, ” the man said

“Just do what I say” the rabbi replied.

A month later the man comes back complaining that the goat smells and breaks everything.

“Sell the goat and come back in a month” the rabbi tells him.

A month later the man comes back to the rabbi with flowers.

“Thank you, rabbi! We ‘re so happy the goat is out, now we have more room and some money! ”

So if you are considering bringing the ORM-goat in, think twice. Or actually, don’t – this way you may enjoy the moment of happiness when the goat will be out, and you’ll return to SQL.

Once in a while experienced software developers post advices for rookies. Giving advices is easier than following them, and here’s my quick set.

1. Being a software developer does not mean sitting all day long with your ear buds creating cools widgets for the Web. Coding of cool things will take less than 25% of your time. The rest of the time you’ll spend communicating to other people. Learn how to be good at it.

2. You know how to do things right. Guess what, other people may have different opinions, and they might be right. Listen, learn, and adjust.

3.While you solutions may have technical merits, there can be other reasons for not doing it “your way “. It’s OK. Do not get frustrated.

4. These 40+ year old farts in the cubicles may not have accounts on MyFace, FaceBook, or Twitter. But that can’t be too dumb if they’ve managed to survive in IT for 15-20 years. May be they know something useful for you to learn?

5. Slow down. You are typing too fast, but the most worn out button on your keyboard is Backspace. Think first, then type.

6. You feel underpaid and being taken advantage of? Hit the job market. You might be surprised – for some reason no one else want to hire you. This may give you a piece of mind and ring a bell – it’s time to study again.

7. You must purchase and read at least five technical books a year. Googling for specific solutions is fine, but you need some more fundamental knowledge. Do not save money on books.

8. Use every opportunity to attend technical conferences. It’ll give you a better sense of where the industry goes so you can invest your time into learning what’s needed today.

9. Start blogging on technical discoveries that you made recently. Even if these little findings may not sound too important for you, they might be life savers for someone. Blogging will improve your technical writing skills and will give you some visibility.

10. Get your Master Degree before you got married. It does not have to be an MBA – get it in the field you’ve always dreamed of. When your significant other will come into picture, going back to school becomes a lot more difficult. “Honey, am I right or am I right?”

This was a quick writeup, and I ‘m sure you can easily add to this list. Be my guest.