reddit's stories are created by its users

join the community, vote, and change the world.

learn more ›

Not happy with Agile, but why? by jbandiin programming

[–]jodonoghue 0 points1 point ago

I should make it quite clear that I wish that I could promote a much more Agile approach in the projects I manage within my company. However, I understand the business factors which make this very difficult.

Regarding the multiple teams aspect, does that top-down plan delivery always work out ok?

It works better than you might expect, but at heavy cost to the engineers close to the milestones and integration points. I would love to be able to meaningfully mitigate this.

We do, of course, use many mechanisms in addition to formal project meetings with all present. However, off-line communication can often be a challenge, especially when cultural expectations/norms are different between the teams.

I have to agree with dodyg as well:

Agile doesn't fix this situation because "delivering a fixed solution on a set date" is very common on Tendered projects and Software Solution companies.

Not to mention Consumer Electronics...

This is why I said in the first point that for me the major problem is that business professionals (salespeople, customers) don't really buy into Agile as an approach. Further success will require changing the business mindset, and that has nothing to do with Software Engineering.

Not happy with Agile, but why? by jbandiin programming

[–]jodonoghue 3 points4 points ago

I'm one of those evil managers who allegedly gets in the way of productivity and good technical solutions.

There are many things which get in the way of Agile in a lot of environments, and mean that adoption is half-hearted at best.

  • Agile represents a process focussed way of interacting with a world which is business focussed. In many industries, what is actually sold to a customer is a 'solution', which will be made available to the customer with some feature set on a given date. Customers don't care how you achieve it, and senior management worry about the cost to the company of failing to deliver. Agile doesn't really address this.
  • In large companies, resource allocation is the major part of what senior people (think VPs) actually do. Their task is to allot the optimal number of people to each of several tens of projects which are overlapping in different ways. They rely on resource planning done by people like me to help them do this. I am usually planning about 18 months out, often on requirements and features which have no real scope attached to them.

  • Teams have different internal priorities, and working a project to completion often requires negotiating these. In many cases (like mine) other teams are probably nowhere near the same timezone - in my current project we have significant engineering teams in the UK, US West Coast (-8 hours), Finland (+ 2 Hours), India (+5.5 Hours) and China (+9 Hours). You can't have a 'whole project' meeting at all.

  • A large project (I work on Smartphone SoC) can have deliverables coming from many teams. Think of, say, delivering Android onto a new SoC. You need (if I simplify massively) a kernel, cellular modem, wifi, display, bluetooth, USB, touchpad, GPS, audio, motion sensors, NFC, ... Most of the preceding are produced by multiple teams involving hundreds of software engineers in total. You cannot afford for each team to decide to deliver 'what is ready, when it is ready'. our customers have a very narrow launch window if they are to profitable, and everything needs to come together according to a master plan (which really has to be developed 'top down'). Agile doesn't really have an answer to this.

The above is just a start. I think the truth is that Software Engineering is hard. Agile is highly applicable to some projects, but it just doesn't map very well to the real business problems of some companies.

Firefox applications are easy by selfdestructive_AIin programming

[–]jodonoghue 1 point2 points ago

From the article conclusion:

Firefox's app architecture let's anyone create their own app store. In general, it's a lot more open. Of course, this shifts the burden of checking the app for maliciousness to the user.

I can't begin to say just how terrible an idea this is. Only a tiny percentage of users has the technical ability to make such checks, and of those who do understand the issues, most will simply avoid the platform as a consequence

Admirable Qualities of a Tech Company by nucleocidein programming

[–]jodonoghue 2 points3 points ago

And a puppy?

The developer in me recognises quite a number of these, but some do seem in conflict with some pretty basic business needs.

"Use own developer machine" - which means the company needs to trust that you keep your Anti-Virus up to date, your machine patched and that you don't keep company confidential material on your machine when you leave.

"Should allow developers too take unpaid vacation" - provided that it's not in the middle of a major code release. Less of an issue with us in Europe, TBH.

"Should assign tasks to developers based on what the developers would like to do" - well, as a manager I try to do this, but sometimes there's work that no-one would like to do. Is this supposed to go undone? My policy is to share out the tedious tasks as evenly as possible.

"Documentation require Microsoft Office" - well, sometimes external documentation needs to be released in a standard format. Can you really get a complex document template just right in <favourite text processing environment>. How long will you take to do this? Why should I pay you while you're doing it.

UML Not Used in Practice? by davidshepherdin programming

[–]jodonoghue 2 points3 points ago

I work in an embedded/protocol environment. We make a lot of use of UML as a design notation. My pet hate is tools which require you to create a semantically correct model of the system - just a waste of time.

However, could I give a huge upvote to PlantUML, which lets us generate good diagrams for design and documentation from text (which means it can be put into our source repo and diffed between versions). This is an awesome tool, and doesn't cost a $SmallCoinOfChoice

My reaction to: How To Exclude Women From Your Technical Community: A Tutorial by doaitsein haskell

[–]jodonoghue 24 points25 points ago


I would +10 this if Reddit allowed.

It is only when you learn to speak another language to a near fluent level that you come to understand the there are nuances to any language which are astonishingly difficult for a non-native speaker to grasp (I'm a near fluent French speaker - and I freely admit to having managed the occasional howler - fortunately my colleagues were quite tolerant, once they had picked themselves off of the floor laughing)

Ironically, this risk is actually at its greatest for anyone fluent, or near-fluent in a language other then their mother tongue. The native speaking listener/reader observes the level of fluency, and tends to assume that all nuance is fully mastered, whereas if the speaking or writing is clearly not fluent, it is easy to make allowances.

Even between different native speakers of English there are small nuances. A British speaker unaware of US idiom asking an American speaker unaware of British idiom for a rubber is likely to get an unexpected, possibly hostile reaction.

In a global network, we all need to be mindful and tolerant of these things - I always prefer to take the starting point that people are not trying to cause offence - if they are, it usually becomes clear later anyhow.

Imprisoned by the Haskell Toolchain (complaints about C FFI) by gtaniin haskell

[–]jodonoghue 0 points1 point ago


Very strong +1 for this.

As someone whose primary development platform is Windows, I am filled with dread whenever I see a library which is compiled with Autotools or anything which depends on Cygwin.

While I agree that Autotools is 'out there' and can, with a (very) following wind eventually be made to work on almost any platform, it is far from doing a decent job of abstracting the platform - at best it just about tolerably abstracts the differences between Posix-like systems, and that is really no longer good enough.

A good start would be a build system which 'just works' for Windows, Linux and OSX. With respect, other forms of Unix are now very much minority platforms whereas the three above must represent around 99% of the installed non-mobile base. In addition, I suspect that a system which worked for the 'big three' would be readily extensible to other Unices.

Scons is actually about the closest thing I have seen, but it brings quite a bit of its own weirdness, especially for cross-compilation.

Oh the fun of trying to install wxhaskell by asdfasdfasdfasdgin haskell

[–]jodonoghue 0 points1 point ago


Errm, it's not that hard: basically download wxWidgets source then ./configure --prefix=/usr/local --enable-unicode --enable-stc --enable-aui --enable-propgrid --enable-xrc --enable-ribbon --enable-richtext --with-opengl make sudo make install

Most of the --enable stanzas are recommended but optional - they get you some of the new libraries and functionality.

It's equally simple for Mac and is rather fiddly for Windows TBH.

Oh the fun of trying to install wxhaskell by asdfasdfasdfasdgin haskell

[–]jodonoghue 2 points3 points ago


wxHaskell maintainer here.

Nearly everything critical which has been said on this page is true.

However... Maintaining wxHaskell is basically a one man operation. I'm not a student with plenty of spare time. I have a very heavy day job and a young family, so wxHaskell gets love when I have the time to give it, whcih is a lot less than I would like.

I do most development on a Mac, but I also maintain 32 and 64 bit Windows 7 Virtual Machines, 32 bit FreeBSD and 64 bit Ubuntu, updated as often as is compatible with maintaining the will to live. They are all UK English machines, so I don't really push Unicode and locale issues.

I try to also keep the most widely available Haskell Platform or its equivalent on each. I also verify against wxWidgets 2.9 (which has significant features and bugfixes over 2.8) and 2.8. I always apply patches received (not always promptly, it must be said - see day job), and I try to keep the wiki up to date with the best digest of what people needed to do to install.

I'd love to build wx from within Cabal, but we already build wxc (the wx binding - nearly all C++) in Cabal, and it was honestly a nightmare to make it work - and wxWidgets is an order of magnitude larger. Cabal really isn't set up to build C and C++ libraries of any complexity - which is fair enough, as it was never designed to.

Just dealing with GHC updates is extensive work in itself. Never actually difficult (update a few library version upper bounds, possible add/change some pragmas), but it all has to be tested against all of the above OS variants, and even then I know I'm only covering the machines used by, perhaps 30% of the user base.

I know that passing unquoted strings to the CLI in the Setup is not very good practice, but no-one has ever told me it failed before, and remember that what I do needs to work for Windows and Unix targets, and up to now it has.

Actually, it does mostly work, but you need to follow the instructions very carefully, and expect (unfortunately) a few wrinkles. I wish it was better, but time just doesn't allow.

If you are using anything bleeding edge (and I regard GHC 7.6.1 as such - it hasn't made Haskell Platform as yet, and I really don't have time to roll my own usable Haskell Platform for Windows or Mac from source), you will see more pain. I'm sure other package maintainers also wish that GHC updates had a lesser record of breaking existing working code.

I'll continue to do what little I can, and gratefully accept help from the wonderful individuals who contribute what they can. This is a labour of love for me (and most Open Source maintainers),and I have never made a cent from it - while it has been suggested that I should allow people to show appreciation using flattr, users, contributions and appreciative e-mail on occasion is plenty enough to keep me going. However, the flip side of being a labour of love is that I get to decide what time I can afford to give, and sometimes other things have to come first.

No wonder CompSci grads are unemployed by tpk1024in programming

[–]jodonoghue 2 points3 points ago


I'm also a hiring manager, and I agree completely. When I interview younger programmers, I find some who are excellent, motivated and will make outstanding team members - it is a privilege to work with them. I also find those who are almost clueless about anything beyond the narrow confines of their degrees.

I usually find that the people who are passionate come in brimming with enthusiasm for their side projects, and enjoy talking about them with me.

Many CompSci and Software Engineering courses are, inevitably, a little narrowly based. That's right in many respects: I want them to help people to think, rather than just churn out "programmers", but this does mean that if you want an edge getting your career started, you'll need to work on some side projects.

Doesn't matter what the side project is (well - it should probably be something suitable for Googling at work ;-) but it gives the chance to work with others, and to learn on projects of a larger scale than Uni coursework typically allows, and Open Source in particular can be an outstanding learning vehicle.

As an example, I currently have an intern who has completed his 2nd year at Uni, and after three months with us is already comfortable making changes to the internals of a microkernel - and doing a pretty good job of it.

tl;dr Some graduates in the field are outstanding. Help yourself to stand out by doing side projects.

There are more than 4000 people in the Haskell Reddit. Tell us what you're using Haskell for! Work and/or play? What would most help you get the job done? by donsin haskell

[–]jodonoghue 1 point2 points ago


In my experience, nothing beats a tutorial approach with a knowledgeable lecturer/teacher and a well thought out set of 'homework' exercises. Not for nothing has this been the approach of institutions of higher learning for hundreds (if not thousands) of years.

In my situation, however, I'm very unlikely to have such an opportunity, and I find that working carefully through a good book can be a reasonable substitute. The difficulty comes where, for whatever reason, a roadblock is reached (e.g. my example of fixpoints in SoE - the explanation given just didn't click with me).

Perhaps there is an opportunity for an online 'Haskell university' to cover this sort of material. The only downside I can see is that, at least for me, Haskell is a hobby, and the cost and regular time commitment required by such an approach might be difficult to justify.

In the end, however, I'd still note that most advanced courses require textbooks, and something which brings together some of the more advanced ideas discussed in this thread would be a very useful introduction - at least to me.

My ideal 'outcome' from such a book would be that I would feel equipped to start to explore these higher level subjects for myself in more detail.

tl;dr; A book is not the perfect medium, but it is one which is highly accessible to many people, especially those for whom a postgraduate level course is not really an option (for reasons of location, time, age, other commitments or whatever)


[–]jodonoghue 1 point2 points ago


That was the one - I think that part of the problem (and occasionally an issue with SoE) is that it's obviously meant to accompany an undergraduate level lecture course, and in this case fixpoints are thrown in as an aside - the kind of thing I'd have gone to ask the lecturer about in my undergrad days.

Haskell Employment by valhalla_coderin haskell

[–]jodonoghue 1 point2 points ago*


[Disclaimer: I do not work predominantly in Haskell] In my day job I'm a software manager in a role which requires primarily high-performance embedded software development in C and/or C++, depending on project.

I have been developing software for nearly 30 years, and, like any professional, I have worked hard to keep myself ahead of the curve, learning new languages, programming paradigms and development environments as simply 'part of the job'.

Haskell is, far and away, the most difficult thing I've done. It has made me reconsider everything about the way I construct software, and has expanded my mind.

While I write a little Haskell in my work, these are mainly 'scripting' tasks which could be done in Perl or Python (although I do them faster and better in Haskell...). The three years I've spent working with Haskell (in very limited amounts of spare time) could never be justified on a purely financial basis...

And yet I look at the gains: my mind is expanded, I'm a better and more productive software engineer, I've received support and encouragement from what I firmly believe to be the most diverse and welcoming programming community in the World.

IOW, my life is intellectually and socially enriched and I'm a better engineer because of it - and being a better engineer definitely pays off financially!

Every language (C#, C++, assembler, Python, Lisp, Haskell) has its wrinkles, but in the end, if you love solving problems, you live with the language - it's simply that some are better tools than others - and Haskell is an awesome tool.

When I hire someone, what I'm looking for most is an open and quick mind, the flexibility to see the interest in many different tasks and a love of solving problems for their own sake.

While my team members spend 90% or more of their time working in C or C++, I would absolutely choose a candidate with Haskell (or Ocaml, or Lisp) or some serious open source involvement over one who has none of these things [obviously they may not choose me if their main motivation is to work in their language of choice most of the time - I can only let them do so maybe 10% of the time].

The problem is that you are looking for a direct payback, and that's rarely the case in life (certainly in my experience).

As an aside, your proposal that you will spend about 6 months learning whatever you choose is far from the mark. You could not become a competent C developer in 6 months (assuming no prior relevant knowledge), and C is about the simplest language there is.

As far as I can see, if your main objective is seeing a direct financial payback for the time you put into learning a language, the three best options are Java, C# and PHP. If you want to make your self more employable by being a better software engineer, you should definitely learn Haskell, even if most of your time ends up being spent doing something else.


[–]jodonoghue 5 points6 points ago*


[Edit: why epiphanies are important]

If I'm honest, there's not so much of a clear road-map after a basic understanding of monads (which I understood just fine once I started to think of a monad as an API with a set of rules, rather than as a bomb factory, spaceship, sack of potatoes or whatever strange analogy Yet Another Monad Tutorial suggested I try to use).

I feel like understanding the relationship between functors, monads, monad transformers and arrows would probably help me to create better architectures in Haskell (I can use monad transformers, but don't really understand why they work, and this bothers me).

Probably more advanced, but more useful, would be to see practical worked examples of using the type system to ensure program correctness - I realise that this falls somewhat into the 'proofs and mathematics' area.

There are small areas which I haven't really seen covered well e.g. use of 'forall' in type signatures (and why I would want to do such a thing), fixpoints (which I didn't understand from the explanation in The Haskell School of Expression), use of type witnesses to model hierarchies etc.

A criticism of RWH for me is that some of the worked examples were fairly lengthy, and sent me into some unnecessary diversions (e.g. the 'Hpodder' example required Curl which doesn't build easily on Windows - I think there were a couple of similar problems elsewhere). Simpler but fully cross-platform examples (or equivalent code where cross-platform is not realistic) would have helped. RHW was a bit Linux-centric in places.

In fact, I feel (and this is somewhere where LYAH is well judged) that very complex (admittedly 'real-world') examples sometimes detract from the basic principle which is being demonstrated.

I think a good approach would be an explanatory chapter followed by a chapter working through the use of the ideas developed in a practical (but not too large) application.

I should add, where the maths is concerned: the main barrier I have found to understanding mathematical explanations is the lack of clear explanation of the terms and symbols used. While I understand that they are an essential shorthand for mathematicians, they also serve to make papers very inaccessible for those who do not 'live' in mathematics (I was an engineering undergrad more than 20 years ago, which is the last time I formally studied Mathematics, so I have forgotten much of the little I ever knew).

Spending a couple of paragraphs introducing mathematical notation before it is used would make all the difference to me (and then by all means use the formalisms once properly introduced - this is absolutely the right thing to do).

Going back to my comments on how I got to understand monads, I think this is where the formalisms are essential. So-called simplifying analogies can really impede understanding if they do not hold water for all cases (as happens in most monad tutorials), so please don't shy away from the necessary explanations

I'd also add that I will be very happy to serve as a guinea-pig for anything you write. I think one of the keys to this type of work is getting feedback from members of the target audience (i.e. those who don't know this stuff, but are motivated to learn). Experts sometimes forget that it often takes an epiphany to understand a complex topic...


[–]jodonoghue 7 points8 points ago


(Disclaimer: I'm wxHaskell maintainer)

I use Haskell as my 'go-to' language for most scripting and tools tasks - and have some success persuading others in my group to do the same. It's peripheral to our main business, which is mobile phone chipset OS software - and at least for the moment I don't think Haskell has a 'story' for this type of work, although I'm hopeful for the future as we have more cores to work with.

Interesting how many people are keen to see a solid set of GUI bindings. I originally took on wxHaskell maintainership because I had just that need in some of the tools I have worked on, and gtk2hs didn't meet my needs (windows-centric, no LGPL allowed).

Problem is that wxHaskell (and I get the impression that this is pretty much true of gtk2hs and qthaskell) are 1-2 person efforts, and at that, mainly people who have day jobs and try to squeeze development into limited spare time.

It would be great if the community could agree on a single GUI binding for Haskell, but I suspect that pride, installed base and licensing wars (I would be unable to use any library that introduces a GPL or LGPL dependency, for example) may make this impossible.

I'd love to fix the many (some serious and long-outstanding) bugs I know about in wxHaskell, do more advocacy, improve the documentation etc, but all I can find is about 4 hours a week :-(

Doesn't help that the day job is hard-core embedded C and C++, so I have a big mental shift when I go into 'Haskell mode'.

So my other 'wish' would be a good set of higher-level tutorial material to introduce me (a.k.a. experienced softeware engineer, clueless mathematician) to some of the more complex topics. There's a definite need for something which goes to the next level after RWH (which I bought twice - once as ebook and once as dead tree ;-)

More tutorials on major subsystems: XML, databases, networking, wx/gtk programming, happstack apps by donsin haskell_proposals

[–]jodonoghue 0 points1 point ago


I have been working on some tutorial documentation for wxHaskell on my blog at wewantarock

Embedded Linux: With friends like these, who needs enemies? by gstin programming

[–]jodonoghue 0 points1 point ago


It seems to me that few of those replying have much experience of designing embedded systems.

MV and Wind River customers have many different CPUs, many different hardware requirements and quite different target applications. Most modern SOC devices have at least some non-standard hardware which will require custom drivers as well. Neither company is likely to ever sell a 'stock' distro, more like a distro kit.

Customers will also require tools support. That means cross compilers, debuggers etc., Emulator support and so on. If you haven't tried building a usable ARM cross compiler from source, then you have no idea what this really means (yes, I do know about Crosstool)...

In addition, bear in mind that at least some customers will use MV as a way of indemnifying themselves against potential licensing issues, and that's a costly additional burden.

Put that way, $60 million is not such a lot, to be honest. Probably less than 100 headcount years.

PyXPlot Users’ Guide A Command-line Plotting Package, with Interface similar to that of Gnuplot, which produces Publication-Quality Output. by gstin programming

[–]jodonoghue 0 points1 point ago


An alternative well worth looking at is Matplotlib ( More functionality, but a more Matlab style interface.

Ask Reddit: Where should I start when teaching a 14yo programming? by militantin programming

[–]jodonoghue 2 points3 points ago


I'd second Python. Easiest language to learn I've encountered, and plenty of power as his skills/confidence grow...

But why not ask him what he'd like to do. Python is good for web type stuff and general programing, but there are a few basic-like languages aimed at games development which may interest him more.

C or C++ is really pretty painful for a beginner (although I started out with raw assembler, so it can be done... showing my age, I guess).

Dear Reddit Programmers: I am about to graduate college and I need your help. by chipwhispererin programming

[–]jodonoghue 9 points10 points ago


I'd second pretty much all of the advice here as well.

And even though I'm the nightmare hiring manger from hell who does know (some) Haskell (so I could test you), berlinbrown is right, I don't have a job in it for you.


[–]jodonoghue 10 points11 points ago*


Well... I'm a hiring manager at a Fortune 500 company which deals in cutting edge embedded technology - slightly off the web design area, but my opinion must be worth $0.01 ;-)

While I usually look for CS or Electronics majors in new graduates, I'd never turn down the chance of interviewing an Ivy league school physicist, especially one who has shown an interest in software engineering (actually, this matters more to me than the major).

However, be aware that you will find the hiring managers at different companies you contact will have completely different policies.

Some just want to see experience (ridiculous requirement for a graduate, IMHO), some want certification. However, the companies with the most challenging work usually want people who can solve problems. In my case that means that I value intelligence, ability to self-learn and solve problems more highly than anything else. Provided that you're not applying to a position which obviously requires experience, your major will not put you at a disadvantage.

I would say that you're only likely to see Functional Programming (at least in its purest sense) in a tiny minority of companies. I can assure you that the FP course you've done will definitely make you a better software engineer.

If you're proud of the websites you've worked on, make sure that you link to them in your resume, and be scrupulously honest about what part you played in the design (i.e. don't claim you designed the site if all you did was change a few of the graphics).

The very best of luck. I think you'll make it.

Ask Reddit: Why is Tk still the standard gui tookit in so many languages? by darrintin programming

[–]jodonoghue 25 points26 points ago


A key issue when it comes to wrapping toolkits for new languages is that most of the 'better' (read more functionality, more standardized look and feel etc) toolkits are written in C++ (the notable exception is Gtk+).

If you're writing a GUI toolkit there are a lot of reasons to use C++ - you've pointed out the 'oddity' of the Gtk+ OO framework in C).

However, most languages provide FFIs for C due to the difficulty (non-standardized name mangling) of supporting C++ compilers, so if you want to write a wrapper for the toolkit, you eventually come around to the fact that you need to first wrap the C++ in C. I work quite a bit on wxHaskell, and about 80% of the code is trivial wrappers for C++ functions to export a C API. You can automate this, and most bindings do, but it's rather painful.

Tk has a very easy C interface - basically send command strings to a small set of easily wrapped C functions. It's readily adaptable to most languages and not too much work to do, As some have commented, the interface is also at a fairly high level, which makes it quite nice to work with (but ugly).

Gtk+ has a C interface - granted a very large one - which again reduces the boilerplate needed. It is also, like Tk, focussed - it's basically a GUI framework with good widgets.

I'm actually opposed to monolithic frameworks which try to do everything. If you're writing a C++ application it's very handy that wxWidgets includes database access, containers and whatever, and renders the cross-platform issues irrelevant.

However, if you're writing a Haskell (or Python, or Ruby, or whatever) application which happens to need a GUI, you likely don't want the database access, containers and so on, as your language of choice likely has perfectly good (and more idiomatic) libraries to do the same thing.

Basically, if you're writing a C++ framework, you want it to cover as many things as possible. If you're writing a reusable GUI framework targetting many different languages, keep it focussed and with a simple C interface which adapts readily to the needs of different FFIs.

I think that the cross-platform GUI asects of wxWidgets are great (I'm a fan of native look and feel on each platform), but it's a pain to work with from other languages in many respects.