What Gas Stations and Yoga Schools Have in Common

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!”

Technical books are getting thinner

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

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!).


“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

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.

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.

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

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

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.