Select Page

Want to be a ZENworks Product Manager?

We’re growing!

There are a few open opportunities within the ZENworks Business Unit for Product Managers.

Ideally we are looking for people who can ‘hit the ground running’.

If you need any additional information – or if you want to apply – get in touch via the Novell email address.

[Edit – the role would probably be based at one of our ZENworks Development Centres – namely Provo, UT, Boston, MA or Bangalore, India]

On engineering, PM and compromise

Someone will get upset at this… Ah well.

Here’s my collection of stuff for an email I’m writing later. Just examples of ‘crap and bloated’.

First – one of my favourite examples from last year; Moishe Lettvin on the Vista Shutdown button:

The whole blog post was mentioned on Joel on Software (a great read; even for a non-coder)

.. here’s how the design process worked: approximately every 4 weeks, at our weekly meeting, our PM would say, “the shell team disagrees with how this looks/feels/works” and/or “the kernel team has decided to include/not include some functionality which lets us/prevents us from doing this particular thing”. And then in our weekly meeting we’d spent approximately 90 minutes discussing how our feature — er, menu — should look based on this “new” information. Then at our next weekly meeting we’d spend another 90 minutes arguing about the design, then at the next weekly meeting we’d do the same, and at the next weekly meeting we’d agree on something… just in time to get some other missing piece of information from the shell or kernel team, and start the whole process again.

I’d also like to sketch out how actual coding works on the Windows team.
In small programming projects, there’s a central repository of code. Builds are produced, generally daily, from this central repository. Programmers add their changes to this central repository as they go, so the daily build is a pretty good snapshot of the current state of the product.

The end result of all this is what finally shipped: the lowest common denominator, the simplest and least controversial option.

Next – a quote that I heard last week again:

“a camel is a horse designed by committee” – Sir Alec Issigonis

Wikipedia is especially complementary about Design by Committee:

Design by committee is a wry, pejorative term referring to a style of design and its resultant output when a group of entities comes together to produce something (often the design of technological systems or standards), particularly in the presence of poor and incompetent leadership. The defining characteristics of “design by committee” are needless complexity, internal inconsistency, logical flaws, banality, and the lack of a unifying vision. Design and style much more relate to intuition and aesthetics than science or politics.

Forcing zman to English

ZENworks Configuration Management is currently in beta – one of the new pieces of the product is the ability to control and configure the client and the server environment wholly from the command line.

By default the command line tool – zman – picks up the server locale. In some cases it is useful to be able to force zman to use a specific language.

Here’s how in beta 3. This may change for the released product.

Edit the file:

%ZENWORKS_HOME%/novell/zenworks/bin/zman.bat (ZENWORKS_HOME is the installation point chosen for the server components)

Modify the line:

“%JAVA_PATH%java” -classpath %MYCP% -Dfile.encoding=%OUTPUT_CODEPAGE% -XX:+UseConcMarkSweepGC -XX:+UseParNewGC com.novell.zenworks.zman.ZManLoader %*

to be

“%JAVA_PATH%java” -classpath %MYCP% -Dfile.encoding=cp850 -Duser.language=en_us -XX:+UseConcMarkSweepGC -XX:+UseParNewGC com.novell.zenworks.zman.ZManLoader %*

Note – all on a single line; differences highlighted.

ZENworks Training

I’m in Provo sitting in on the first round of formal training for the two new products ZENworks Orchestration Server and ZENworks Configuration Management.

The training looks fantastic; right now each track has 2.5 days of deep dive hands on labs.