We all know that passwords ought to be strong - strong enough to withstand common attack vectors, such as brute-force dictionary attacks or plain guessing. Most software systems with identity management also incorporate some kind of password policy enforcement and their configuration options (here, here, here and here).

There are even commercial standalone tools focusing on enforcing password policies. For example, the Password Policy Enforcer by Anixis or Specops Password Policy. Many of these products enable administrators to define policies and configure rules to prevent users from chosing weak passwords and comply to corporate security policies.

In this blog post, I'd like to show the principle steps in implementing a password policy enforcement component using flow rules, decisions and scoring (bonuses and penalties) to calculate the strength of a given password using Visual Rules. In contrast to commercial tools, which often already integrate with domain controllers, this example only shows the rules, not how it could be integrated into the Windows domain or into a web application.

• Comment (1)
• Trackbacks (0)
• Continue reading "How to implement password policies using business rules modeling"

How does my company/my team score at The Joel Test?

Let's see...
1. Do you use source control? YES
2. Can you make a build in one step? YES for most products, NO for others.
3. Do you make daily builds? YES
4. Do you have a bug database? YES
5. Do you fix bugs before writing new code? NO
6. Do you have an up-to-date schedule? NO. Either it changes too often, or stuff gets moved, or we're behind the schedule because we forgot something to do.
7. Do you have a spec? NO
8. Do programmers have quiet working conditions? NO. Coders interrupt each other very often.
9. Do you use the best tools money can buy? NO. The only good commercial tools are PL/SQL Developer and JProfiler. All others are open-source or other free tools with bad usability or incomplete integration (e.g. The Gimp, M2Eclipse)
10. Do you have testers? NO
11. Do new candidates write code during their interview? NO
12. Do you do hallway usability testing? NO. Occasionally we do, with at most 1 other "user".

Final score: 4/12

According to Joel, that's above average, but still too bad. We'll have to work on that.

The things i'm going to change next:
5) - fixing existing/known bugs before writing new code/new features.
2) - making all our high-level builds automated, not only single artifacts.

What concerns me most is point 7), although I haven't got a clear idea why and how to write a spec for something which is already being built. The current plan is to use the user's manual and developer's manual, extract abstract information and then detail it out into an architectural overview documentation.

• Comments (0)
• Trackbacks (0)

What are Dynamic Applications?

It's the software-way of putting the business people back in charge. Today, changes to enterprise business software takes ages to get into production. Endless analyze-redesign-implement-test-deploy cycles affecting multiple stakeholders: IT, QA, vendors and of course the sponsor.

How would it feel if the first three stakeholders could be removed from the process, once the application has been finalized in its initial state? How about giving the sponsor or business department the ability to adapt and change applications on their own? How about giving them the ability to change complex business logic, fine-tune parameters and model work flow to reflect the reality when and as soon as it changes?

• Comments (0)
• Trackbacks (0)
• Continue reading "Dynamic Applications"

With Coding Horror, Jeff Atwood has one of the best programming blogs ever. Yesterday he blogged about The Atwood System of Real Ultimate Programming Power, which I find so great that I need to repeat it here, for the sake of marketing:

DRY

KISS

YAGNI

I would really like to inspire my collegues. I want them to read blogs, to read programming books, to improve themselves all the time. Some of my team's members are doing this. Some don't. And as Jeff wrote, the guys who really need improvement are not the ones reading blogs at all. They just don't care.

Late Friday evening, just before Kai and me went off to get some beers in Markdorf, another team's member told me that his day had gone really bad. He wanted to do a pre-release for his customer and the day ("Freitag 13.") seems to have put all kinds of strange errors on his way. Like Maven not resolving dependencies, Hudson not building for two days, ActiveMQ losing connections etc. I was shocked that he didn't try to find the root cause of his problems and fix them (like learning how to control Maven and do real releases, instead of pretending to do releases and just do it manually), but he put in most of his effort to work around the problems. Fixing symptoms never helps.

He spent hours to work around all kinds of errors, instead of fixing his release process and to get it right once and for all. I bet that his team will have the same problems on the next release anyway and that they'll start crying at Maven all over again. Just for the sake of "I don't care how this complex software engineering thingy is supposed to work, i just want to get my crappy code packaged somehow so I can send it to the customer, forget about it and get home asap."

• Comments (0)
• Trackbacks (0)

Yesterday was a tough day in some way. Just when I thought we would finally get some time to work dedicated on the project, clean it up, implement new features, updating the documentation etc, a call from management interrupted .. well, the whole working day. The project had some interesting life time so far, as it's used for various specific solutions and each time we created a new branch for the customer, so the project teams working on that version can make their changes, patches, updates without disturbing anyone else and vice versa.

However, each time we created a new branch of the software library, the administration gets more and more complex and chaotic. And now, we're going to have yet another branch due to a tight timeframe. We can't settle on the current HEAD and work on it until it's done - that'd probably just take too much time and the customer-projects need it within a couple of days.

It could be worse though. (And yes, it's going to be worse, I dare to predict that.) It's not that we haven't got any tests or not have continuous integration etc. We've got all that. But that alone doesn't make it work right. And to make life even more interesting, the team's increasing. We'll have to find some time to instruct the new developers and they need time to familiarise.

Please wish us luck

• Comments (0)
• Trackbacks (0)