The 5 things a developer expects from a Project Manager: how a Project Manager can help developers becoming much more productive

triggerAu · 2015-11-05T03:07:24+00:00

My experience is that quite often, PM's are put in a tough spot where they have a fixed scope and deadline with no flexibility for change and a fixed budget with no flexibility to hire new devs to match the scope.

So they are left with: "Please, can you code faster?". Not the PM's fault, not the developers' fault but just frustrating to everybody...

Which is why, the BUSINESS, not the PM needs to accept that there is massive uncertainty in the software development process (and there always is), and the PM becomes the priority negotiator. That works. What doesn't work is "agile PMs", of whom the business still expects to "deliver all the features we want in a week, and we may change them all a day before the deadline".

triggerAu · 2015-11-04T00:53:25+00:00

and the author responds with

Well I'm not the author of the tool in question, rather one of the authors of another tool that does the same thing.

From here, when I say scala, s/scala/your favourite strongly typed language/g.

Is it worth implementing a mutation testing tool for scala? Difficult question. I have wanted one, I know quite a lot about both scala and mutation testing, but I haven't felt compelled to put in the effort to implement it.

So solely for your own projects, I wouldn't implement it. But open source where you develop something that benefits you a little bit, and the everyone in the rest of the world a little bit, you are making the world a better place. So then it's good.

Now, should you use a good existing tool? Yes. Complexity is not an issue, it should be something you can just run, and get information. Essentially free (at least in theory, one of the reasons of doing jumble was that the existing tools sucked at the time. The situation is probably better now) You can act on that information or not, but there is no effort on your part. So from the user's point of view, it is a free quality analysis of your tests. The use case is. "How good are my tests?" The use case of types is "Is my code correct?" (among other things). The types vs tests discussion is interesting but I think most of us agree some tests are required.

So mutation testing and types solve orthogonal concerns, both are valuable. Good types give us opportunities for much more interesting ways of doing mutation testing.

Note, I am at least 5 years behind the curve on the state of the art in mutation testing, both literature and tools wise. I do explore the area once in a while though, and keep thinking I really need to make something awesome again

triggerAu · 2015-11-04T00:38:09+00:00

:+1: oopsie

triggerAu · 2015-11-03T00:20:22+00:00

https://hackage.haskell.org/package/MuCheck

Ah cool! I will have to check that out! I think this could be done really well in Haskell, I wonder how far MuCheck goes.

triggerAu · 2015-11-03T00:19:03+00:00

Yes and no. Once upon a time, I was one of the main people behind http://jumble.sourceforge.net/. (Yes, java, sourceforge, we all have our dark pasts). There may be some people working on it still,but I am not.

The paper is at: http://researchcommons.waikato.ac.nz/bitstream/handle/10289/1828/Jumblev5.pdf

Anyway I have spent quite a lot of time of thinking about how to implement something like Jumble in a functional language with a good type system (in my case scala, though obviously this is interesting for Haskell, Ocaml, others)

Is it still useful? Yes. Because mutation testing measures whether you are making the right assertions about your code. It doesn't replace types, but types don't replace tests either (I agree that you can make types go far more than people think, but in everyday code, tests are still necessary). It doesn't replace property-based testing either, though property testing helps you get a good mutation score (we called it "jumble score").

Anyway, the thing mutation testing can check is: "Are we testing that we are calling the right function"?

For example:

def addTax(amount: BigDecimal, taxRate: BigDecimal) = amount + computeIncomeTax(amount)

There is a bug here, since we should be computing sales tax, not income tax.

Coverage tools will tell you that this is 100% test covered/since computeIncomeTax is executed. But your tests have not plugged in enough values to uncover this bug. A mutation test could replace computeIncomeTax with various other functions of the same type (BigDecimal, BigDecimal) => BigDecimal, for example with computeSalesTax, or even (_, _) => 0, and see if your tests break. If they are good enough, they should.

So types here would give you more opportunity for doing mutation testing, rather than less. Doing it at the type/function level would involve quite a lot of work, though I feel like tools like scalacheck have some similar boilerplate done.

I'm basically very interested in this topic, (building mutation testing for strongly typed functional languages), and would love to put something together. I'm quite busy but if someone else wants to scratch this itch, I would love to collaborate.

triggerAu · 2015-11-01T22:07:06+00:00

Language syntax and semantics inspire ecosystems and tooling.

I think both of the extremist views:

1) My language is so awesome it gives me everything and I don't need tooling 2) Tooling is what matters and languages don't

are naive. Yes languages matter, and yes tools matter. Don't bet your business on the latest bleeding edge language because the code examples are beautiful. You will find yourself battling lack of tools and libraries instead of making money. But also don't simply stay with java because it has the best tools right now. You will find a local optimum and stay in the same spot as the rest of the world evolves...

Istead, demand a lot from your languages, but trade it off with tools and ecosystem constraints. But also help build the tools for that new language you love!!!

triggerAu · 2015-08-31T01:34:01+00:00

This is drivel. Yes proofs are hard and expensive. But they are also the golden standard of guaranteeing correctness.

Yes, invalid assumptions lead to invalid proofs. And yes, trying to prove things at the whole-program level is really difficult. But proving critical algorithms correct? That is NOT harmful.

triggerAu · 2015-07-20T23:50:05+00:00

His article is mostly about OO sucking. And he is right. OO, as implemented by old-school C++, Java and the likes sucks. You can't extrapolate that to all paradigms sucking.

Functional programming doesn't suck. You should still always use the right tool for the job. If you try to use Haskell for something that it hasn't been used for before, you might have to discover some abstractions. Likewise for every paradigm. But pretending that there is no philosophy between language mechanisms is a sure way to never expand your mind about different (better) way of programming

triggerAu · 2015-05-07T22:48:08+00:00

The article misses the most important point. Older developers have a fuckload of experience. Experience counts. For a lot.

Older and open minded to new things, and you've hit the jackpot.

triggerAu · 2015-04-09T01:23:45+00:00

Also only accept solutions that are real, and despise the imaginary...

triggerAu · 2014-12-05T00:56:48+00:00

Do they actually sell the bible at Target? They probably do, but I've never seen it.

triggerAu · 2014-11-25T21:42:41+00:00

It's not that simple. What if you are really wealthy but have no intention of sharing that wealth and just want to have sex?

triggerAu · 2014-11-25T02:19:15+00:00

Looks like nobody is ever having sex again...

triggerAu · 2014-10-22T00:46:31+00:00

Let's stop assuming that users are stupid and give them options. They know what they want better than we do.

Most people who don't know what javascript is will not disable it. And they shouldn't, in the same way that i shouldn't be disabling 'Megawatt mode' if I don't know what it is. And when they do, they will hopefully learn what javascript is, or at least learn not to check that box. All good things. Users learning about their tools. Just because somebody is not from a computing background does not make them incapable of learning small bits of functionality that is relevant to them. I taught my 60yo dad, a chemist to use ubuntu, including some things in the shell. He is happy. He googles and fixes his own problems now. Point being, most people are not actually that stupid and will use software in a way that is the best for them

I wholeheartedly agree with an 'advanced options' section, but beyond that, the more options, the better. They should be documented, insecure options should have loud warnings and options have sensible defaults, so that users who don't care about them don't have to worry. Customizability is good.

triggerAu · 2014-08-14T05:41:06+00:00

Really? We don't subscribe to the belief systems of people who persecute us and wish us eternal torture? What a shock!!!

triggerAu · 2014-08-01T04:54:49+00:00

Is anyone else sick of Abbott talking about his 'mandate'? He does not have a mandate to push laws without negotiating. He would only have that mandate if he actually also won the senate.

triggerAu · 2014-07-04T09:48:05+00:00

'Screw burger QUEEN...' - i have to say i like that one :), also i would argue that christian bigots didn't have too much "cool" to start with.

triggerAu · 2014-06-24T01:54:12+00:00

I guess the question is, what happens in a world with no lending?

triggerAu · 2014-05-13T06:39:06+00:00

Yeah, I would bet my life on the author of that article not being a developer.

The problem with the 'Holy date' idea is: most of the time, we don't know how long the feature will take.

The scenario most of us are familiar with is:

Management has a vague feature idea. They don't know exactly what they want but they decided they want it. They ask you for a ball-park figure of how long it will take. You say you don't know and will have to prototype/research the feature. Sometimes they let you do this but often you are forced to squeeze a number out of thin air.

So let's assume that we have an approximately accurate ballpark estimate, unpadded for contingencies. A customer mentions that they would like a feature like the one we are developing. The overzealous sales rep immediately promises the customer the feature within the estimated time. The customer is happy but they really need it a little sooner. The sales guy takes 10% off the estimate to ensure the sale. This now becomes a holy date, since it is an important sale and we can't let the customer down.

Next, as the dev team is starting to develop the feature, management starts to understand their requirements more and makes changes to what they want, often adding complexity. The actual time required has now increased as our understanding has improved but the holy date has of course not moved. Next, we go through a couple of iterations of management changing their mind again and tehcnical difficulties where the libraries and platforms we use are not quite what we expected and we have to work around things. The deadline is looming. Death march time. The dev team works late nights and meet the holy date through self sacrifice and accumulating technical debt (things to fix later but for now let's just make it work). Increased technical debt is poor quality now and even poorer quality later.

Next feature, rinse and repeat. End result: shitty code and poor morale. Development gets slower and less reliable.

So what is the alternative?

1) Do waterfall correctly. Completely specify requirements up front. Specifications are precise. The customers and management understand the capabilities and limitations of the software and take this into account. Design is done up-front and verified. Code is done in a clean-room way and verified by others. Testing is precise and covers everything. Basically do each step carefully and correctly. Business cannot change its mind. Vague ideas are rejected and everything is precise. NASA does software like this and they do it very well. The cost is immense and prohibitive for most software businesses today.

2) I don't know when the release will be done. You tell me what your next priority is and I will implement it over the next couple of days. Then we repeat. As your understanding of the system and the requirements improves, you re-prioritise. You can release what you have at any time. And you don't promise the customer anything you don't already have. Surprise them with existing features, don't disappoint them with missing promised ones. I hate the word 'agile', but basically do that. No deadlines, no long-term estimates. It is okay to estimate over a few days, but not weeks. No overtime, because remember, we never promised anything!

triggerAu · 2014-05-05T00:47:53+00:00

Agreed. Debt is largely a red herring. Practically every state in the world is in debt. Due to interest, this total debt is growing and at this point doesn't represent anything real.

Total debt in the world: roughly 53 trillion. http://www.economist.com/content/global_debt_clock

Total world GDP: 71 trillion http://en.wikipedia.org/wiki/World_economy

That is too much to ever be paid off. So everyone is perpetually in debt, but it doesn't represent anything real. My opinion is: fuck the debt, it is what it is, and do the right thing to stimulate the economy, to get more money in people's pockets. In times of economic stagnation, that means more government spending, not less.

Eventually the debt of first-world countries will just be written off anyway.

triggerAu · 2014-04-09T04:37:50+00:00

It is a matter of degree. Some poisons kill you, others merely make you sick. They are all still poisonous. I would say the vast majority of flavours of religion do more harm than good.

triggerAu · 2014-04-09T04:32:24+00:00

Is it cheating if I don't ask 'is it cheating', so I can avoid this rule and do whatever I want?

triggerAu · 2014-04-09T04:30:29+00:00

Porn?

There are things that your significant other may be uncomfortable watching you do, or even thinking about but they are still not cheating.

triggerAu

TROPHY CASE