Category: software

What Gas Stations and Yoga Schools Have in Common

Published on by Yakov Fain4 Comments

In the past two days I attended a party with Gas Station owners, and then a Yoga school. These two events gave me the material for this blog. So what do a gas station and a yoga school have in common? Both types of small businesses use software. What a revelation! To be more specific, in both cases I saw the room for improvements in software.

Actually, I started writing about gas stations eight years ago. Senior (literally) Java developers may remember the times when reading printed glossy magazines on software development was a norm of life. Eight years ago I wrote a series of articles under the category “Yakov’s Gas Station”, which was printed in Java Developers Journal. You can still find them online.

Anyway, during the party conversation my wife mentioned an episode at a gas station that happened a couple of years back. We live in New Jersey, which is one of two privileged states where people are not allowed to fill gas tanks themselves. You pull down to the pump and keep sitting in a car like a tsar. The gas attendent will come over and will do the rest. He started filling my wife’s car at one price, then changed the price (increased) on their large billboard, then came back to the car trying to charge this transaction at a new price. My wife didn’t agree, and after a short and colorful conversation she won (what’s new?).

Our friends (gas stations’ owners) told us that in New Jersey it’s illegal to continue pumping gas if the the gas station owner needs to change the price. The owner should stop operating all pumps, change the price, and then resume work. This is how it should work in theory. But in the real life, you may lose customers if they’d be asked to wait. I was surprised that the gas station owners didn’t see it as a big deal.

I started to tell them that there is a better software solution, which could be implemented allowing continue pumping gas and changing the price without affecting the customers who are in the process of getting filled. Software developers know that I was thinking of implementing proper synchronization locks that would freeze the price that was in effect when the pumping started. Why it was not done? Software architects didn’t care about these small business owners, which would accept that “This is how the system is set up and we’ll use it this way“.

Now the Yoga school. They sell various types of monthly and yearly memberships that would allow attending unlimited classes – as many as you want. The problem is that I don’t need this all-you-can-eat option. Going there twice a week it more than enough for me. Any other options available? Yes, you can purchase 10 sessions at a discount price and attend them on an a la cart basis.

Now we are talking! Can I buy these 10 tickets and share them with my wife? No, the system is not set up this way. Sure, they’ve designed the database linking these tickets to the members’s ID. It’s a wrong software solution again. Why not keep things simple? A ten-session ticket is supported by a single database table with two columns: tktID and RemainingSessionsCounter? The customer comes in, hands the ticket to the girl who scans or enters the ticket number into that computa, and the program decreases the counter. Simple? Yes. Good for the business? Yes. Good for the customers? You bet!

The problem is that software creators have to build their systems based on what the customers needs. Yes, the customer may not know any better, but what about you?

Four years ago I was a part of a small group of people who created a startup for automating small-scale insurance business – the agencies. Back then agents were using a mediocre software that was available. We had almost no knowledge about how the small insurance businesses operate. But we didn’t like what we saw. Insurance agents also didn’t know any better. Today, more than a 100000 agents across the country are using our software called SureLC. They are happy, we are happy.

Steve Job once said, “People don’t know what they want until you show it to them.” So if you are about to automate a business, don’t just have write software implementing existing workflows. Think about the customers, and when your next system will go in production, people will say, “Wow, we didn’t know it was possible!”

Advertisement

Technical books are getting thinner

Published on by Yakov Fain10 Comments

While working the upcoming book on Web development, I keep stopping myself from writing too much. And this is what I want to talk to you about.  In the past, technical books were a lot fatter than today. A typical book on computer programming was a thousand pages long.  If the author(s) wanted to cover a set of related technologies (like J2EE or .Net) the book could span 1500 pages or more. People were used to read books because Google, Stack Overflow, Youtube and Vimeo were not invented yet.  Today, majority of software developers are googgling trying to find a code snippet to copy-paste, and the smaller part of the programmers watches video recordings from conferences.

I’m not sure if O’Reilly started this “Get Slim” movement, but recently I ran into their book, which was only 60 pages long. Want to be a published author? Easy. Write sixty pages and update your resume. This is yet another example of devaluation in action. The next step is to increase the font and add some comics-style illustration like in books for children.

I’ve just have submitted a 38-page chapter on selected HTML5 APIs, where I reviewed History API, Web Messaging, Web Workers, Offline Web applications, Web Storage, and IndexedDB.  Can these materials get a decent coverage in 38 pages? Yes, if the reader has some background in Web development and know how to self-study. Yes, because the code example are focused on the covered API as opposed to offering a 200-line code samples of which 180 lines is the author’s favorite set of utility functions, which he uses daily.

When you submit a proposal for the book, the publisher asks for the estimated number of pages.  A year ago we estimated that the book would have 600 pages. Most likely it’ll have a little more than  650 pages, which is a really thick book by today’s standards.  I also know that we’ll get several  reviews stating that the book doesn’t cover some of the topics in depth, which is perfectly fine. The main goal of a good technical book is to ignite the reader’s interest to a covered topic and give some   kick in the right direction so googling will become more educated and fruitful.

Do you read technical books  or it’s too old-fashioned? If you do, what’s your preferred book size?

How to Present new Software Releases

Published on by Yakov Fain2 Comments

If you run a product company, you have to release new versions of your software. In the USA the mantra is “Never undermine your product”. Because of that, the most popular words in describing the software produced by your company are great, fabulous, fantastic, or simple the best. Important: never speak negative of your software. 

Say, you’re releasing the version N of your software product. Over the last six months your software engineers were working long ours trying to fix 159 critical bugs reported in Jira and 573 non-critical ones. Ten new features were added in this version, and finally Release N was pushed out the doors.

Your firm runs an annual conference for developers, and you are delivering a keynote about the new release N. This is how you should open the keynote (remember the mantra!).

Dale-Inflating-Balloon

“Hello guys,

Thank you for your continuous support of our Software. The version N-1 of our Software was fabulous. We are the leader in this market. But we wouldn’t be who we are if we wouldn’t be always trying to find new solutions and make our Software even better. The Release N is simply the best in this sector! Das ist fantastisch! 

The performance of the Software N-1 was always beating the competition. But we were able to tripple the speed of network communication in version N.  The UI in version N is the richest UI ever – we doubled the number of our UI components.” If you have time left, do a very light intro to the list of new features introduced in N. This will discourage some smarty pants from the audience from embarrassing you by asking geeky questions like “Have you resolved that showstopper bug in your rendering engine that crashed our application three times a day?” But if someone will ask you a question showing that this guy knows your software better than you, gust say politely, “We can take it offline. Just grab me in the corridor after the talk.” I can guarantee, that after giving such an answer no one will grab you anywhere.

Everyone knows that release N will reveal a bunch of new issues and the release N+1 will fix them and add something extra. But who cares what’s left behind? Look forward, move ahead, inflate your importance or else…

P.S. If you’ll ever hear me presenting a new software product of our company in such a manner, do not buy it from me. Most likely this software is full of crap as well as the presenter.

Applied Adapter Design Pattern

Published on by Yakov FainLeave a comment

Design patterns in software are pretty often explained in a boring dry language that works as a sleeping pill (yes, I’m talking about that white book). The Head First Design Patterns tries to make the process of learning designer pattern funner, but IMO the Head First books you can’t see the forest for the trees. Future technical books should be short, fun to read, and up to the point. In today’s world Wikipedia often gives you a decent answer in a street language without too many words. For example, here’s how Wikipedia defines the Adapter:

The adapter pattern is a design pattern that translates one interface for a class into a compatible interface. An adapter allows classes to work together that normally could not because of incompatible interfaces, by providing its interface to clients while using the original interface.

photo
While teaching object-oriented programming, I tell my students that objects in programming represent objects from the real world. One of the examples is an adapter for a traveler.

Recently, I ran into another real-world example of the Adapter pattern, which may resonate well with my students. I’m talking about bras. Take a typical situation, your girlfriend wears large cup sizes, but if one manufacturer labels them as 36DD, the other calls them 36G or even 36FF (devaluation in action).

This is where the Adapter would help. Software developers at HerRoom.com applied this pattern (they called it Universal Cup Sizing).
bra And now, when you’ll be shopping for the gift for the upcoming Mother’s Day, just visit this site, enter the size and brand of one of her existing undergarments and get the universal cup size. Shopping for bras was never that easy, thanks to the Adapter pattern!

Offtopic. Twenty years ago, when I arrived to the USA and went to a large home improvement and construction store asking for bra, they were surprised and tried to politely direct me to a different store. The thing is that bra in Russian means a lamp hanging on the wall (see http://bit.ly/Rr0g8g).

Me no talk English? Me no good programmer.

Published on by Yakov Fain8 Comments

Our company, Farata Systems, hires lots of offshore developers who work for us and our clients from the Eastern Europe, which has plenty of good developers. Ten years ago, Indian developers were more competitive comparing to Russian-speaking programmers for only reason: their English was better. You may not believe me, but not only they could read, but all of them could even speak English!

The situation is slowly changing and more and more developers working from behind the iron curtain (btw, is the cold war over yet?) can speak English. While interviewing developers living in the Warsaw Pact countries, I speak Russian for the most part, but always switch to English for five minutes or so.

Why do I want them to speak English? Of course, some projects require direct communication with our clients from the USA. But we also run internal projects where no communication in English is needed – the entire team can speak Russian. We still want them to know English, and for a different reason. In today’s IT world, almost 100% of the latest and greatest information is being published in English: books, blogs, screencasts, videos, conferences, Stack Overflow, and other forums. Sure, some of the books will be translated into other languages… in several years. It’s a bit too late. Google Translate might somewhat help, but it’s a stretch.

If a software developer does not know English – s/he doesn’t belong to our profession. S/he doesn’t care to master the latest and techniques and technologies fresh from the oven. Your English doesn’t have to be perfect (I’m sure some of the native speakers will find poor grammar in this blog too), but you must know and use English to be better programmer.

Last year, someone asked Douglas Crockford, a JavaScript guru, if junior developers have something in common. He gave a very good answer, “Lack of curiosity”. I’d add, ” and poor English”.

The Code Review Day

Published on by Yakov Fain7 Comments

No, it’s not about the peer code review. Colleagues go easy on each other. They get lazy. They can’t be held accountable if a low quality code will sneak into the final product. Ain’t broke, don’t fix. I know about code coverage tooling too. They can help to some extent. But nothing beats the code review performed by a team lead. You can’t even imagine what can you find in people’s code.

First of all it’s like “Lost and Found”. The amount of the dead code is substantial (I know, some code quality tools can find it automatically). But morst importantly, people write poorly structured and inefficient code that can be easily identified by an experienced eye.

– Why did you write three loops, couldn’t you do it in one?
– Yes, I meant to change it later, but just forgot about it.
– We’ve agreed on using a fluid grid on this screen, where is the CSS?
– Sorry, I decided to cut corners cause the proper CSS was not obvious in the first place – I’ll change it now.
– What was the point of modularizing the application if you load all the modules on the application startup?
– Oops, no worries, give me a couple of hours and I’ll fix it.
– Why is this variable static? Do you really need to share it between all instances?
– C’mon, don’t be anal picky. You know how it works. Ok, give me an hour.

Let’s announce the first working day of the month
“A Code Review Day”.

During this day the most senior person in your team does nothing but reviewing the code of more junior colleagues. It’s not likely that you have more than 4-5 developers per team lead. Allocate two hours per person, and you’ll be surprised. You won’t believe your eyes. You’ll start pulling your hair out. You’ll be laughing and crying. Yes, people can write such code. They are not bad people, and you can keep going for a beer with them. They just don’t care. Sometimes. Ain’t broke, don’t fix.

Don’t get frustrated. Don’t report your findings to your manager. Just quietly and politely ask people to f#@ing clean this mess! The next month do it again.

Now, when can you say that the code is written well? I’ll tell you the secret. I’ve learned it while writing programming books. Here the rule:

“The code is good if it can published in a book”.


The readers are mean. They are not forgiving any little mistake. Most of them would never survive a book writing project, but they are happy to point at every little problem in your code samples. If you are a team lead, use the same tactics – read and ask to explain each questionable line of code, but be nicer than the readers.

Agreed? Propose “The Code Review Day” during the next team meeting. If your developers are standing during such meetings ask them to sit down, cause some may faint when they hear this.

That’s all there is to it. Please share your success story if you’ll manage to implement this practice in your organization – just add a comment to this blog.

The Framework Coder on the Tractor

Published on by Yakov Fain3 Comments

My previous post “The Degradation of Java Developers” sparked several interesting discussions. One of the major topics was if today’s developer has to know what’s going on under the hood of a particular framework. To be more specific, if Hibernate, a popular object-relational framework, can hide from your how the database objects are being created or manipulated, why learn SQL? One reader stated, “First of all, Hibernate (JPA, actually) is a step forward since it reduces most of the boilerplate SQL of the obvious kind. In applications with around 100 tables in the SQL database it is not challenging to explicitly write data access objects by hand.”

I can agree with this to some extent, especially when we talk about such mature and stable framework as Hibernate. But this framework was created to spare the programmer from writing tons of mandane SQL and JDBC code. Hibernate might help you here, but it’s hard to imagine that if the storage consists of 100 database tables no queries created by Hibernate have to be fine-tuned and optimized. In such cases if a person who uses Hibernate doesn’t know SQL – it turns him into a useless team member.

About two months ago I was making my usual morning promenade along the beach. Every morning a couple of tractors are moving back and force leveling the beach surface destroying the sand castles and burying butts and seaweed. All of a sudden, one of the tractor’s wheels got stuck in the sand.

The driver started angrily pushing the pedal or whatever else there is to push, making the tractor move back and forth slowly but surely getting deeper and deeper into the sand. When the tractor’s belly was literally laying on the sand, the driver realized that he won’t be able to get the vehicle out of the sand himself.

I was observing the entire show from the beginning of submerging till the moment he started to call for help using his cell phone. This is when I took the picture. What struck me the most was that during all this time the driver didn’t even bother to step down from the tractor to do anything manually to prevent the submerging. He didn’t bother and he was not trained for these kinds of situations. I assume he was told to call the office in case of any extraordinary situations. Houston, we got a problem!

Do you see the analogy with a framework coder who doesn’t know how things work under the hood? I clearly do. I also know that among the tractor drivers that are working on that beach there are people who know how to fix these situations without calling for a tow truck.

On the same note, each team of programmers includes a person who knows how to fix everything starting from fine tuning SQL all the way to fixing broken builds or writing manual piece of code that performs better than a framework.

Some developers who use open source frameworks know that if there is a bug in the framework or some feature doesn’t exist they file the bug or request for improvement with the vendor and then happily report to their managers that we have to wait till the vendor will fix it. But there are people who understand the words “open source” literally. Yep, they open the sources, read the code, subclass the problematic classes and make the fixes on their own.

The question is if IT managers understand and promote those people who are not afraid to roll out the sleeves. It helps if the software developers know how to manage the manager. But this is a topic for another blog.

P.S. Replacing SQL with a 500-page long JPA spec “to make my life easier” is not a good idea unless you really need various types of data storage. In 99% of the today’s enterprise applications it’s not needed. But my kudos to the Sun/Oracle tandem for brainwashing millions of Java developers into believing that learning JPA is better than learning SQL.

How to make your Chrome browser work faster

Published on by Yakov Fain6 Comments

Any Web browser has local cache, and everyone knows that its goal is to minimize the number of network requests by caching locally some resources like images or even the program code. The google.com home page opens blazing fast? Sure, because the browser loads it from your disk cache, not from the network.
But let me question this holly grail of all Web browsers. Does local cache make your Internet browsing faster? I have two different ISP at this location. Take a look at the speed of my Verizon FIOS wireless internet connection produced by speedtest.net.

Optimum Online is my second ISP and below is their data. Both ISP show pretty respectable speed, aren’t they?

Now back to local cache. Being a Web developer, I use several Web browsers to make sure that my JavaScript (a.k.a. HTML 5) applications look good on four major browsers. A regular person may not know a little dirty secret of Web developers – they often turn off the cache to make sure that the Web browser will always pick a fresh version of the application being worked on.

Recently, I started using Google Chrome for personal Web browsing. It’s a nice browser, but I noticed that some Web sites started loading really slow. Cleaning cache often helped. So I decided to make a more radical move – I simply disabled cache once and forever. Man, my Chrome started flying!

If you want to try this experiment too, here’s how to do it. Click on the image of a little wrench at the top right corner of the browser’s window, and select Tools | Developer tools. The bottom portion of your window will show the panel depicting the guts of the Web page you’ve been looking at. Then click on the little round Settings icon at the right bottom corner of the page. It’ll open a new panel, where you can easily find the Disable cache option. Just do it and let me know if you’ve noticed the difference. The same trick should work with other Web browsers too – just goggle on how to disable cache in yours.

A Bad Guy Inside my Notebook

Published on by Yakov Fain3 Comments

This week I’m in Seattle, WA teaching Adobe Flex at the client site. Everyone in the classroom was given a password to the local Wi-Fi router. Everyone but one person successfully connected to the Internet. This unlucky guy was me.

In fact, my notebook was connected to the router, but that was as far as I could reach. OK, I was the only person using MacBook. Can this be a problem? Checked the network settings – everything looked hunky dory. I got a valid IP address. One of the students went to see Da Man – sysadmin, who gladly confirmed that my IP address has been blocked by the router’s software. Why? Yakov’s machine makes lots of connection requests to random IP addresses in a short period of time.

Students started to make fun of me – a minute ago I was explaining how to process financial data feeds from unoccupied Wall Street and students suggested that I must have been involved in a heavy-volume stock trading while teaching the class. I wish! Since May I’m working for another client sitting on a trader’s floor, where I had to sign an agreement that made trading impossible (insider’s information, you know).

Opening Activity Monitor on my machine didn’t show anything suspicious – the only running programs were MS PowerPoint, Acrobat Reader, Eclipse, and Skype. Another student suggested that it might be some virus or antivirus software installed on my machine. Wrong. Ain’t using Windows – me no need antivirus. Me no have viruses.

How to find out who makes all these network calls? Good old Charles network monitor came quite handy, as usual. I started this sniffer, and sure enough, every couple of seconds a connection attempt was being made to some IP addresses…

After shutting down Skype, the problem was solved. Skype was the bad guy trying to make all these connections! This makes me wondering, does Skype tries to poll each of my contacts who’s online? This must be the case. We reported my findings to the system admin, who unblock my IP, and the next second I saw Google!

The lesson learned: always have an HTTP sniffer with you if you ever want to see the light of Google’s home page.

Sad Experience: Doing Business With Avacorp

Published on by Yakov Fain10 Comments

Avacorp is an IT consultancy with headquarters in Edison, New Jersey. Their employees are located in the USA and India. According to their top management, the size of the company is more than 100 people.

In July of 2010, our company, Farata Systems, has been hired to develop an application for one of the Avacorp’s clients. I was leading a team of seven developers from our side, and Avacorp was managing the project, performed test, business analysis, and the data base administration.

Per our agreement, Avacorp had to pay for our work on the Net-30 basis, which meant not later than 30 days after receiving an invoice. After the first month of work we billed them and continued working for another month. So during the first two month our team of seven developers works, they were getting paid from Farata Systems funds. No big deal – we work with many clients under similar agreements.

After two months of work I decided to find out from Vivek Dhamodharan, Avacorp’s CEO when are we going to get paid. For some time he simply didn’t pick up my phone calls. When I got lucky, he explained that there are some difficulties, and they’d pay a portion of the amount and the rest shortly. OK. We kept working for another month and sent the second invoice. I made a follow up call asking regarding our payments. Vivek said that their client had financial issues and would resolve them shortly, and then Avacorp would pay us.

At this time the amount of unpaid invoices was way north of $100K. Each of our developers was getting paid regardless of these issues, and we decided to stop the development. This time Avacorp started bombarding us with emails explaining that this was their very important client and we should continue working.

We didn’t work on this project for a month. This was a force major situation for us – the entire team of our developers was out of project on a one day notice. After a month, Avacorp stated that their client found the money and we’d get paid, and had to put the same team back together to continue working on the project.

I responded that we are willing to continue working if Avacorp would start pre-paying a full month work based on the month-to-month signed agreements. This was a Time and Material project so we “d be multiplying the rates by the man-hours to calculate the approximate amount. Avacorp started to beg to go easier on them, and we agreed on taking 50% of the next month amount sending them an invoice with the factual amount at the end of each month.

Each month we’d sign the Scope of Work (SOW) document for the next month listing resources/hours they need. All this time the work of our developers was closely managed by a project manager from Avacorp, who was satisfied with the quality of work we provided.

By May of 2011, the application was almost ready and the size of our team shrunk to 1.5 developers. By May 15 I asked if we should keep the same developers in June, and were told that Vivek would be sending us a new SOW shortly. It didn’t happen.. Despite that, I kept the key developers working on this project till the last day of May.

On May 31, Kiran, the project manager of Avacorp contacted me stating that the project won’t continue in June, but our developers would still need to finish a couple of lose ends. I asked if Avacorp was planning to pay for it?
“No. Since some milestone was not met, you’d need to do it for free”.

I responded, “Kiran, this was a Time and Materials project, we never agreed on being paid only if certain milestones were met. Besides, you’ve been managing our developers till the last day and was happy with their work. If you believe, that our developers didn’t deliver quality code, I’ll tell them to fix what they did wrong for free “.
“No, they worked fine, but there is something else to finish”, said Kiran.

I know that something may go wrong, and nobody’s perfect. But I was not asked about a favor. I was told that we must do this job. We rejected, and apparently Avacorp’s developers fixed those small issues on their own.

It’s mid August, and we’re still waiting for Avacorp to pay us for the second half of May for the work that we completed as per their requirements. Vivek keeps promising … Nine days ago he sent us a polite email with the following content:

“Apologies for the late response. We should be able to confirm the date of payment this Monday it will be this week. Sorry for the delay. We value your relationship and it has been mutually very good. Will give you a call on Monday to confirm the wire date.” Needless to say that we didn’t get a call till today.

Anyone who ‘s running a company knows that sometimes delays in payments happen. This was happening to us too with the clients as small as two-person startups or as large as multi-billion dollar corporations. But we never had a situation when the client simply didn’t want to pay and postpones this moment by any means.

Are we the only vendors of Avacorp having issues with payments? Apparently not. We found the site http://ripoffreport.com where another vendor complains about the same.

The more the merrier. The class action law suit can be the only way for us to get paid for the work that we did.