Symphony of Science

31. July, 2012

When I reach to the edge of the universe
I do so knowing that along some paths of cosmic discovery
There are times when, at least for now,
One must be content to love the questions themselves

– Neil deGrasse Tyson

Symphony of Science is a YouTube channel where they mix awe-inspiring images with vocalized texts. It’s a bit hard to explain but easy to understand. Watch this:


Excellent Explanation of PermGen Issues

27. July, 2012

If you develop web apps, you have encountered java.lang.OutOfMemoryError: PermGen.

Nikita Salnikov-tarnovski wrote an excellent article where these come from and how to solve them: Busting PermGen Myths


Musicians Need Strong Copyright Laws to be as Successful as They Already Are

25. July, 2012

When I read “Britain’s share of the global music market is higher than ever” (source) and “We can only realise this potential if we have a strong domestic copyright”, I can’t help but wonder: Isn’t the industry so successful because they have the today’s laws?


Software Development Costs: Bugfixing

21. July, 2012

(Second part of three; first part is here)

Software has bugsthere simply is no way to avoid them. If you can’t avoid them, maybe you can handle them efficiently? Yes, you can:

As you can see, the cost of fixing bugs rises as time passes. Why is that?

There are many reasons:

  • When you find a bug a couple of minutes after you created it, you probably still have all the information in your head that is necessary to understand and fix it.
  • If you just created the bug, no code depends on it. As soon as you start writing unit tests and more code, fixing becomes more expensive because you start to have dependencies.
  • People might have gotten used to the bug and developed workarounds. If you fix the bug, this will have an impact on them.
  • A bug found in production is likely to be reported by a customer. Customers can’t see inside of your software, so extra effort will have to be spent to determine what the actual problem is. Google for “how to report bugs
  • When a bug is discovered at the customer, it might trigger meetings and scapegoat hunting. Think of it this way: A 1 hour 8 person meeting costs about $1’000. And no bug was ever fixed in a meeting.
  • Some bugs escalate to the top-level management. Imagine for a moment what it would mean for you if their CEO called your CEO to complain about a problem you caused.
  • Bugs might break expensive things, harm or even kill people or start World War 3.

This also explains why unit testing is so much more efficient to QA testing for many kinds of bugs: It simply catches them before they spread their bad influence.

So fix your bugs early, OK?

Related articles:


CBI or Taking The Pain out of Eclipse Builds

20. July, 2012

When a project is young and dashing, mistakes are made. The PDE build process is such a mistake. If you ever tried to build Eclipse (or at least some of the older parts), then you know that this is brittle and the error messages are more like mysterious ramblings of an angry deity than helpful.

Enter stage CBI. From the FAQ:

 The CBI build of the Eclipse platform is intended to produce the same output as the PDE build, and thus facilitate packaging without noticeable change. The noticeable difference the CBI build of the platform makes is ease of use to build the platform. For example, the prototype has consistently demonstrated that a newcomer without prior experience can build the Eclipse platform with under 30 minutes of effort on a machine with a supported JDK & Maven.

What can I say?

Finally!


Chrome Experiments

19. July, 2012

If you want to see what’s possible in today’s browsers, go to Chrome Experiments.

My picks:


Designing DSLs

16. July, 2012

Hello and welcome to a new series of blogs called “Designing DSLs” or DDSL for short. If you have used or designed a DSL before, then you’ll know that there are a couple of pitfalls. This blog series aims to provide tips how to build “great” DSLs – whatever that might be ;-)

What are the most common pitfalls for designers of DSLs?

  • The DSL is too broad
  • The DSL is too limited
  • The syntax has weird quirks (a.k.a. backwards compatibility syndrome)

Why is it so hard to design a great DSL? They should be simple, right?

Well, as Einstein (“Everything should be made as simple as possible, but no simpler“) and Blaise Pascal (“I would have written a shorter letter, but I did not have the time.“) already knew, it’s always easy to make something complicated – simplicity is hard.

On top of that, every mathematical system is either incomplete or inconsistent. And let’s not forget that each DSL is a model, too. And as you might know, all models are wrong but some are useful.

Should we abandon all hope? No. Just always remember that a good DSL is hard work.

First, a general tip: Look at existing examples. There are thousands of examples out there; use them. Knowing several programming languages yourself is a big bonus (everyone should know more than two languages).

“Wait a minute,” I hear you ask, “these are real programming languages!” So? A lot of brainpower went into designing them (or working around shortcomings), which makes them a great source of inspiration. Bonus: A lot of people know these languages which gives you a larger audience to discuss ideas (as opposed to the 3-4 people who will use your DSL in the beginning).


Software Development Costs

14. July, 2012

I’ve prepared a small presentation to give an overview of software development costs.

This diagram describes the costs/gain per feature.

Complexity Curve

The most simple curve, complexity, is easy to understand: Costs go way up as you add features. Adding another feature to an already complex product is way more expensive than adding the first feature to a non-existing product.

Bugs in Final Product

The number of bugs in the final product is harder to understand. As you add features, you also add bugs. The number of bugs per kLOC is an individual constant. We always make the same mistakes and we the number of bugs we create per kLOC is pretty stable, too. The number is different for each person but every developer has their own number and that number doesn’t change much unless external circumstances change dramatically. In fact if you create statistics about bugs found per team member, you can tell how many new bugs there will be after he added N lines of code (see “They Write the Right Stuff“).

That means every product has bugs. If the project isn’t a complete disaster, then the team will have found a way to cope with these. Or to put it another way: If the number of bugs grows too fast, the project will either be canceled or drastic measures will be taken to reduce the flaws again.

This is what the curve means: In the beginning, there will be few bugs because there are only a few lines of code. Remember: number of bugs = lines of code * individual constants. Each line that you don’t write reduces the number of defects.

As time passes, the number of bugs will grow just because lines of code are written. Eventually, that number will either explode or the team will find a way to keep the number in check.

Gain per Feature a.k. ROI

The last curve is for the marketing department. It describes the usefulness of the product for a customer as features are added. A product without features (a.k.a vaporware) is not very useful for a customer. The first feature will be the most useful … or it should be: Why are you wasting your and your customer’s time with features that aren’t the most useful?

But as you add features – and trust me, customers and marketing will try to get as many as they can get – the usefulness doesn’t grow as much anymore. Each feature comes with the cost of complexity: There will be more menu items, dialogs and buttons. The manual will get bigger. The customer will need to remember more to use every feature. That starts with remembering that a feature even exists and goes on with remembering how to use it efficiently.

At the same time, you started with adding the most useful features, right? So additional features, by definition, can’t be as useful as the first ones.

And eventually, the product will contain more features than any single customer cares about. New features will be added for new customers that existing customers don’t care about or that even get in their way (when menu items move around, for example).

This is one reason why everyone feels that Google or Apple products are so easy to use: They work really, really hard to reduce the number of features in their products.

Next week: Bug fixing costs.

Related:


Dealing With Cheating

13. July, 2012

All online games attract cheaters. Most of them try to ban players who cheat but Rockstar Games came up with a better approach: They herd them.

Makes me wonder what took them so long. It would be great if there was a special server for cheaters and people using modded clients. Just imagine how many people will start working on AI problems (identify threats, take cover, shooting at targets, move around in a complex maze).


TNBT: Bringing Code Together

12. July, 2012

If you develop web apps, you have a workflow like this:

  • Repeat forever
    • Edit code
    • Deploy to server
    • Check in browser
    • Tweak HTML/CSS in browser
    • Find the location in the code which is responsible

Sucks? Yes. But until recently, there simply wasn’t a better way to do it. Only Eclipse allows to run am embedded web browser in your IDE but there is no connection between the code and the output. There usually isn’t a connection between related parts of the code. Or can you see all the relevant CSS styles while you edit code that generates an HTML tag? I mean: Can you see the CSS styles for “.todo” when you hover your mouse over code that means “send ‘class=”todo”‘ to the browser”?

Meet Brackets and see how awesome your IDE could be. If seeing is believing, here is the video:

Related Articles:

  • The Next Best Thing - Series in my blog where I dream about the future of software development

Follow

Get every new post delivered to your Inbox.

Join 333 other followers