Slashdot is powered by your submissions, so send in your scoop


Forgot your password?

Comment And when you copy those two lines... (Score 1) 808

... from BSD licensed code, you preserve the copyright notice and the license, right?

Thought not, although that's about all the license requires you to do if you redistribute the code.

People seem to think BSD carries no obligations whatsoever. I guess I've never heard of anyone suing for violation of the license.

Comment But why should I care? (Score 4, Insightful) 50

I just read through your whole site, but I have no idea what MSS Code Factory is, what problems it solves, what it would do for me or why I would want it. I get that it generates code from a model using a bunch of rules, much faster than a human could type it - but that is rarely the critical problem in writing code.

Now, I've worked with various code generators and high level modelling tools for decades, and none of them have been worth the effort so far. The effort involved in learning the system, working around the inevitable bugs in it (usually involving having to keep patching the output again and again as the model evolves), and interfacing with the bits the model can't handle just make them an exercise in frustration. It's a bit like the old regular expression joke.

I'm not saying yours is the same; for all I know it's totally awesome and doesn't suffer from the same problems as all the other ones I've had to deal with - but you are so into your own project that you've forgotten how to explain why anyone else should care.

Take a small step back, put yourself in our shoes, and tell us why we need it.

Comment Passion, people skills & experience (Score 1) 743

I've sifted through hundreds of CVs and interviewed over 50 people. It's hard finding good developers. I don't think puzzles or other forms of intelligence test by proxy are a good way of finding them.

I try to get candidates to talk about the work they've done and communicate what was interesting about it. That one filters out those who don't really care. I also ask about situations where a commonly held way of doing something should NOT be applied. That filters out the ones who've got all the "right" answers by book learning, but haven't actually thought about it themselves. I also ask some ambiguous questions to see how they deal with them.

I've offered jobs to people who got many, many details wrong, but clearly demonstrated they were into writing good software and were easy to work with.

Comment Re:Document (Score 1) 735

I just left an organization I'd been in for 8 years, so I was also leaving behind a fair few systems. The guy who was taking over most of them had all the documentation he needed to operate the systems. So I do agree that documentation is really important (although sadly often neglected).

What he didn't understand was why it was like that in the first place. What came out of our discussions before I left was the history - the decisions, compromises, optimizations, and mistakes that shaped them. I could see that afterwards he really got it, and felt confident to take them forwards. It made me realize how almost all documentation presents things as finished products, leaving out how it arrived in that shape.

Of course, if you're hit by a bus, all you have is the documentation.

Comment Re:Federal Records Regulations to Blame (Score 1) 148

Retention policy rules have to be fairly simple (in the paper world and the digital world), or they simply don't get applied. But each organisation is supposed to have their own specialised retention policy which spells out exactly what kinds of material should be maintained, archived or destroyed.

Having spent nearly 8 years working for the UK National Archives, I can attest that the main problem with managing digital records is that retention policies are generally not applied at all to digital material. The stuff just builds up in file servers, databases, email systems and other apps. Record managers are still largely stuck in the paper world and don't see the playthings of the IT department as anything to do with them.

In this case, there appears to have been an active internal policy of deleting certain kinds of digital material - when this material should have been retained according to the retention policy agreed with NARA. Anytime I see a department deleting digital material, it's because they really, really don't want to hold on to it. The default position of doing nothing is the norm.

Comment Re:Not a 100 year project (Score 1) 364

Well, it's good that it isn't looking at a single company then. And that they're not trying to build a starship before it's remotely possible.

The whole problem they're looking at is to try to figure out exactly how investment in and commitment to very long term projects (but ones with profitable spin offs along the way) can be sustained. A starship is a good basis for such a project; it's not doable with current technologies, but we can already imagine ways in which it could be achieved. The problem is probably not primarily technological (without wishing to trivialise those problems). It's more of an organisational, possibly psychological, and certainly economic issue.

Comment Not a 100 year project (Score 1) 364

The 100 year starship project is supposed to study what it will take to sustain private sector investment into a long range program of building a starship.

It is not itself a 100 year project to build a starship, or a 100 year project to figure out how to sustain investment...

Also, if you're interested in interstellar research, check out Centauri Dreams:

Comment Re:How does this voodoo work? (Score 1) 141

I don't think homomorphic encryption provides values for true and false or provides comparison operators - only one operation (e.g. addition) or two operations (e.g. addition & multiplication over a ring).

I do like the idea of arriving at known values through some basic arithmetic though - I'm just not sure the operations provided permit this.

Comment Re:How does this voodoo work? (Score 1) 141

The whole point is that, without the decryption key, you don't know what the result of any processing is. Even were an attacker be able to process the data in some way, they would not know what the result meant. Remember that encryption only deals with confidentiality, not integrity. If you want to be sure that an attacker has not processed the data in some way, you would need to add integrity protection of some sort to your data in addition.

Anyway, since you don't have to decrypt the data first in order to perform operations on it, you can do most of your processing without ever having the data in the clear. Only when you want to learn a result do you need to decrypt. I'm really not sure why you don't see the potential security benefits of such a scheme. The overhead has no bearing on the security, other than its slowness preventing it from being used in the first place.

Comment Re:3 companies, 3 agile failures (Score 1) 196

I totally agree with what you say. Agile is not the absence of planning. You still have to do a lot of requirements gathering and analysis. Some architectural issues need careful spiking to ensure you will meet non-functional requirements.

Agile is not anarchy - it's about controlled and collaborative change in exploring a complex problem space.

Comment Re:3 companies, 3 agile failures (Score 1) 196

That isn't Agile development - it's just poor development. Good agile development doesn't cede control of the development process from developers to customers, any more than good waterfall takes control away from customers and gives it to developers.

In both cases, it requires strong product management - and this is not undertaken by the customers or the developers in either case. Taking scrum as an example, you have the role of product owner, whose job it is to ensure that the right things are being built. Scrum only provides a way for customer feedback to occur and influence the development process during development, as opposed to waterfall where requirements are agreed up-front. One good thing about scrum (over waterfall) is it explicitly has processes for the development team to agree how much can be built, and how it will be built (which can be absent in a waterfall process).

So I strongly disagree with your assertion that agile takes control away from developers. When it works well, it creates a highly collaborative environment in which both customers and developers agree on what will be built, how long it will take, and whether further refinements are necessary. However, this does require a strong product owner to interface between them.

Comment Re:3 companies, 3 agile failures (Score 1) 196

In general, I agree with you. No methodology is a silver bullet that will magically transform a bunch of mediocre people into a tight, intelligent productive team. In fact, I would go so far as to say that most methodologies exist to mitigate the effects of the mediocre. A really good team of people can produce great code no matter what methodology is presented to them (even if they have to work around bits of it sometimes).

I successfully introduced Agile development into my last organisation, which was very much a traditional waterfall style, make-promises-we-can't-keep-but-at-least-there's-a-plan sort of place. We adapted the methodology to fit the organisation to some extent (mostly scrum, with a bit of kanban thrown in, and interfacing it all with traditional Gant chart people). It worked pretty well - mostly because the people we had were really committed to making it work, and I worked double-time on getting the organisation on board, particularly inviting them to sprint-reviews. It created a buzz - and the organisation was sold on it - which helped a lot.

In my new role in a much smaller organisation, I'm not so sure it will work as well - so I'm holding off a bit until I get the measure of the place. I have really talented developers - but communication and visibility is not a big issue due to the small size of the place, and people tend to work individually on tiny projects rather than collaborate as a team on small bits of shared functionality.

Anyway, Agile won't make mediocre people great, and Waterfall won't make great people mediocre. There are advantages and disadvantages to each style of development. The one thing you really do need to make great code is at least a few great (or at least, highly committed) people.

Slashdot Top Deals

You can tune a piano, but you can't tuna fish. You can tune a filesystem, but you can't tuna fish. -- from the tunefs(8) man page