We have decided to address JavaScript with more care. We’d like to give it the time and focus it deserves. Not to be mistaken, we are probably in the top 5% of businesses going deep into JavaScript on our enterprise software, but we still feel we can go further — especially in the fields of quality assurance and scaling.

Lo and behold, we give you;

Monday School Notes from JavaScript session #1

Table of Content

We have decided to divide the subject of JavaScript into the following sections:

• Development Tools
• Coding standard
• Guidelines
• Frameworks, or the lack thereof (when to use what)
• Testing
• Debugging
• Patterns
• Document Object Model (DOM)
• Productivity tips
• Compatibility issues
• Recommended reading/watching

We’ll be covering these topics in the weeks to come, and we well be returning with links on the TOC. If you will join us in this, please follow this blog on RSS or follow the company or the author on twitter. If you digg it, then digg it.

a) Ease of Use

The software solution walks you gently through the process of solving your problems as intended. No distractions, no unnecessary decisions to make, no confusions, always heading towards the goal. In short : A great user experience.

b) Quality of Craft

Quality of Craft means that the software solution is easy to maintain, it’s easy to modify so that it’s always accurate in solving the ever changing problems it’s going after (and by that I don’t just mean in configuration, but easy to change the code of), it’s easy to move about (i.e. from server to server), it performs great, it responds immediately when interacted with and it scales, or can be modified to scale, in order to handle the traffic it will attract.

Photo by toffiloff

Isn’t that an intuitive definition?
The definition is common sense in software product development.
Perhaps a “Software Product 101” should start out with such a definition.

Thus, we should assume that everyone get’s this nailed down from the start, or through a little experience, no?

I’m sorry to report that surprisingly few players in the industry is able to see this.
And even fewer is able to execute it.

It’s always either or, never both. The tendency is quite prominent.

It seems as start-ups create great solution accuracy and a good user experience using customer oriented development methods, and in general a lean start-up methodology. Growth, however, turns them in the direction of stability and the need for predictability. Sadly this usually leads to a loss of the qualities in a) in favor of a few of the more stabilizing qualities in b).

As much as I agree that as a start-up turns into an enterprise, the need for operations stability and predictable performance increase. I do not, however, believe that this is achieved best by sacrificing the ability to adapt and to keep the software usable and accurate.

I believe that while sacrificing qualities in a) might seem to be the easiest path, it is not the only path, not to mention that it in no way is the right path.

I am part of a small, growing, start-up company, and we’re focusing our resources at keeping on the right path, maintaining the agility of a start-up, and the stability and predictability of an enterprise. It is possible — this path exists.

It’s hard to find. But we’ll find it, or die trying.

Related posts

• A post about buildings (and software quality).

Problem 1. Foot-in-the-door Software

The recipe for creating foot-in-the-door software is really quite simple:

1. Design a software that can do anything with “a little customization”.
2. Make it hard to customize. Make every protocol and specification proprietary and hard to understand.
3. Don’t go anywhere near any standards.
4. Provide a horde of overpriced consultants to fix all of the above problems, and have them apply the “Ninja Technique (Problem 3)” so that they can stay on-site indefinitely.

Voilá! Now just wait for money to pour in from miserable customers.

Solution: Empower your customers through creating standards compliant API’s and plugin environments with open and commonly used technologies for which problem solvers can be found everywhere and anywhere. Even better, stop creating problems for your customers in the first place. Stop sticking your foot in the door, and focus on creating something that makes your customers the stronger one. They will rely on you all the more for it — and it will be a relationship based on trust, not desperation or despair.

Problem 2. The Green Lights Problem (Unchangeable Bloatware)

Players in the industry still build software that is close to impossible to change or make additions to. It can take months or years between releases, and they buffer up so much change that no-one ever dare (or can afford) to upgrade. This frightens the purchasing department. Big time. As a reflex to this problem, they have (understandably) rehearsed their spec writing to include everything but the kitchen sink — effectively forcing anyone that want to be a player in the industry to create bloatware from day one rendering the software hard or close to impossible to use, as well. A 100 page requirement is not that uncommon(!) 20% of the required features typically end up being used (*). The longer the spec the better, it seems. It means less risk of having to ask for a software change from a broken industry — let alone taking the risk of going through actually receiving it! Purchasing is happy though, they did their best to fight change by getting their little green lights on all checklist points in their gargantuan spec, and then they moved on never seeing the havoc in the wake.

This quote from It’s Learning shows just how bad it can get “We need not concern ourselves with the users, as long as we make money” Meaning that they’ll throw anything into their software to please purchasing, even though it makes the users miserable. (via Ida Aalen and google translate, original post in norwegian here)

Solution: Dear Industry, let’s at least start by creating usable (as in usability), modifiable and maintainable software, effectively showing the customers that we can please both the user and the purchasing department all at once: changes and additions to the spec is possible without a headache, which allow us to keep software functionality concise and to the point. Happy users and happy purhcasing = happy everyone. Even you. Look to lean and agile for your solutions embracing, not fighting change. It’s possible, you know. It just might lower costs and increase your overall software quality, as well.

Problem 3. The Ninja Distraction Technique  (using Tech Jargon)

The software industry has spent years (or maybe decades) educating their customers in tech jargon. It’s all a part of the ninja technique of distraction. It is. Really. The theory goes: Keep throwing words such as “Java, JBoss, Caching layers, Multi Tier Software Development Housing Fascilities Campus” at the customers, and you will not only sound very professional, but what’s even better, the customers will soon forget what they really were asking you for, so there’s less of a chance chance you have to deliver.

Imagine being the customer in this scenario: Here you were looking for a a) safe car with b) comfy seats, c) low fuel consumption, d) good stereo sound and a e) large trunk for all your groceries, and suddenly you had a car salesman giving you a primer in everything ranging from the new four layer varnish coating technology to the latest in air-pressured suspension theory and revolutions within the field of fuel injection and what not. You don’t want to hear about that, you want to know if it will hold your coffee cup steady while playing your Mozart in a perfect pitch.

Well, the industry seems to have distracted you from all that.

Solution: It’s about time the industry starts talking about the metrics that the customers can relate to and understand. And more notably, the ones that they need. Let’s talk about ease of use. Let’s talk about performance (can you handle 100 users registrations a second?). Let’s talk about modifiability (can you deliver a medium sized product feature change in 1 week, or less?). Let’s talk about reliability. Is your up-time average more than 99,97%? Will your software automatically restore upon any hardware problems? Can you upgrade our software frequently without involving our tech-department? What is your fix time for bugs?

There is no need to talk about technologies if you can reassure the customer on the real metrics. If you can deliver on these metrics (and deliver you can if you just stop with all the distractions), you would not need to apply your ninja techniques, and our software could be made by an aging brontosaurus for all they would care.

Let’s shift focus onto providing real software solving real problems for real users — injecting relief instead of frustration and hopelessness into this world. (**)

Please contribute with any experiences you have with the industry in relation to any of these problems. Or maybe you have a beef of your own with the industry. Bring it on! We (the players in the industry) desperately need to hear it in order to improve.

Footnotes

(*) This is my personal estimate, based on the pareto principle and experience. However, probably not an unfair estimate given the magnitude of this problem.

(**) Am I trying to convey that we’re perfect in this respect? No. We’re improving all the time.

Tune in to the fourth dimension using RSS or follow me on twitter.com/geirber