NiXPS
Monday, October 19, 2009
Software Design Review
I'm a regular reader of a Philip Greenspun's blog.
He has written an interesting article on the subject of 'Software Design Review'.
The problem he tries to tackle is a classic in the field of software development: how can non-technical management manage a software project. It sounds a bit silly, but it really is a problem.
Small and large software project all over the world fail miserably for years, and still are failing.
From small 'in company' projects, to big government funded undertakings, the reality anno 2009 still is that these projects are delivered not in the given time budget, often perform poorly, do not function properly, etc...
Philip Greenspun's argues that the software development process is too opaque, and that it needs proper third party design review at the start, during and at the end of the project.
It's an interesting proposal, and it it can be seen as having an external technical on-site stakeholder present all the time. This certainly makes sense, as I agree that a lot of projects are suffering from a lack of focus, and regularly a re-calibration of the business goals is healthy to spot problems early on, and deliver on-spec, on-time, on-budget.
However I do taste quite a bit of bureaucracy in the proposal, with al lot of documentation that has to be produces during all the steps.
A lot of outsiders to the field tend to compare software building, with real building (like in a building a house). But this analogy doesn't hold true.
First of all, software is not build from ready made, fully specced, 'parts' Nobody guarantees you anything when talking about 'software parts'. Some have SLA's, but even then a lot of things are 'unknown', 'not tested', 'never tried', 'fixed in next version' etc...
Experience also learns that it is very hard to have a fully fleshed out and final design before construction, as the 'architecture' tends to evolve based on changing requirements. This is why the Agile development practice leads to better results than the Waterfall method.
But I do support the call to lift the practice of software development to a higher level. And being both a software developer and running a business, I also do think that the practice of developing software needs a more formal methodology, and lead to more predictable results. ¶ 22:04 0 Comments
He has written an interesting article on the subject of 'Software Design Review'.
The problem he tries to tackle is a classic in the field of software development: how can non-technical management manage a software project. It sounds a bit silly, but it really is a problem.
Small and large software project all over the world fail miserably for years, and still are failing.
From small 'in company' projects, to big government funded undertakings, the reality anno 2009 still is that these projects are delivered not in the given time budget, often perform poorly, do not function properly, etc...
Philip Greenspun's argues that the software development process is too opaque, and that it needs proper third party design review at the start, during and at the end of the project.
It's an interesting proposal, and it it can be seen as having an external technical on-site stakeholder present all the time. This certainly makes sense, as I agree that a lot of projects are suffering from a lack of focus, and regularly a re-calibration of the business goals is healthy to spot problems early on, and deliver on-spec, on-time, on-budget.
However I do taste quite a bit of bureaucracy in the proposal, with al lot of documentation that has to be produces during all the steps.
A lot of outsiders to the field tend to compare software building, with real building (like in a building a house). But this analogy doesn't hold true.
First of all, software is not build from ready made, fully specced, 'parts' Nobody guarantees you anything when talking about 'software parts'. Some have SLA's, but even then a lot of things are 'unknown', 'not tested', 'never tried', 'fixed in next version' etc...
Experience also learns that it is very hard to have a fully fleshed out and final design before construction, as the 'architecture' tends to evolve based on changing requirements. This is why the Agile development practice leads to better results than the Waterfall method.
But I do support the call to lift the practice of software development to a higher level. And being both a software developer and running a business, I also do think that the practice of developing software needs a more formal methodology, and lead to more predictable results. ¶ 22:04 0 Comments
Wednesday, October 14, 2009
NiXPS View 3.0 features: XPS Notes
One of the exciting new features of NiXPS View v3.0 is the ability to add notes to an XPS document.
We invested a lot of time and in effort in this, as we were faced with a few challenges.
Not the least the fact that the XPS specification doesn't have the annotations functionality built-in.
Which either gave us the option to not implement it at all (like competitors do), or work around this limitation.
We feel that notes are a compelling addition to the to the XPS format, especially on Windows, where this brings XPS to a much higher, more usefull level. So technically we are working around the limitations of the XPS spec by putting the notes in the XPS content. This ensures that other, non-notes aware XPS Viewers show the notes information.
In NiXPS View you can manipulate an delete the notes, in other viewers you merely view them.
To counter the effect of not being able to move a note in a non-NiXPS Viewer, we made them transparent, allowing to see what the note covers (in NiXPS View you can hide the notes, or move it).
So in summary: NiXPS View allows you to annotate XPS files, and in such a way that they are visible in every XPS viewer too.
Here is a demo of the notes feature:
We invested a lot of time and in effort in this, as we were faced with a few challenges.
Not the least the fact that the XPS specification doesn't have the annotations functionality built-in.
Which either gave us the option to not implement it at all (like competitors do), or work around this limitation.
We feel that notes are a compelling addition to the to the XPS format, especially on Windows, where this brings XPS to a much higher, more usefull level. So technically we are working around the limitations of the XPS spec by putting the notes in the XPS content. This ensures that other, non-notes aware XPS Viewers show the notes information.
In NiXPS View you can manipulate an delete the notes, in other viewers you merely view them.
To counter the effect of not being able to move a note in a non-NiXPS Viewer, we made them transparent, allowing to see what the note covers (in NiXPS View you can hide the notes, or move it).
So in summary: NiXPS View allows you to annotate XPS files, and in such a way that they are visible in every XPS viewer too.
Here is a demo of the notes feature:
NiXPS View v3.0 Notes Demo from nixps on Vimeo.
¶ 11:54 0 Comments
Tuesday, October 13, 2009
Adobe recommends disabling JavaScript to avoid PDF hack attack (again)
Dixit computerweekly.
Ah - the pain of being popular.
Or maybe, because the format got a bit out of hand.
The other day I found this gem: PDF/D
Oh yeah, yet another PDF/something subspec, this time a PDF subspec that is really, really, for documents.
Hence the 'D' - see?
And they have committees and consortium and everything like the real grown-ups have.
I think we're close to having a PDF spec for every letter of the roman alphabet, the joy! ¶ 12:18 0 Comments
Ah - the pain of being popular.
Or maybe, because the format got a bit out of hand.
The other day I found this gem: PDF/D
Oh yeah, yet another PDF/something subspec, this time a PDF subspec that is really, really, for documents.
Hence the 'D' - see?
And they have committees and consortium and everything like the real grown-ups have.
I think we're close to having a PDF spec for every letter of the roman alphabet, the joy! ¶ 12:18 0 Comments
