Jeremy Hutchings

I’m happy to see lots of people supporting and stating the obvious about this topic. Though I thought I’d add my 2c to the demise of this all to common evil of open offices. They are typically favoured by individuals who like to interrupt others, and also by those who look to short term visible costs. Open offices are likely the single biggest cause in companies of: The lost of human happiness The lost of team/individual effectiveness The lack of success of companies and projects I rank them in that order for importance as well, as that’s the order I’ve typically experienced them being absent in successful projects. I believe the mental state of the members of the team, and the collective teams health is a core (if not the primary) factor in successful outcomes. It’s good to see the academic community supporting (with research) what many have felt and known to be true for so long [1] , I’ve spent many years in different office environments, when I haven’t

While I'm using Drupal on some projects as an example, I'm not singling Drupal out for criticism for the sake of it, and not ignorantly either as it's the CMS I have most production project experience with (opposed to vBulletin, though when I worked creating that, it was a forum - and not trying to be anything else). The purpose of this post has to do with my thoughts on : Choosing the right tool (and starting point) for the job. Knowing not only why, but that you have done so, as no project or pieces of software is ever "done" till two things happen. Firstly when it's stopped being worked on, and then it will last as long as it is robust, and secondly when the server is turned off. Everything from conception up to the first stage is "the development of a software system", releasing it or putting it on a server is just one part of that, typically when customers (hopefully turn up and) need supporting. It's also usually at this point that if

Creating New Sugar CRM Graphs I've recently been working on a project that required some custom chart additions to SugarCRM. At time of writing the project is using the Community Edition, which according to wikipedia has 85%~ of the code base that the Professional and Enterprise editions do. I think I'll have to side with Dan Farber from CNET with concerns over how SugarCRM uses the term Open Source - it's not really. Especially considering that I'm working with the charts module, which is one of the main pieces which has been removed from the AGPLv3 license in Sugar 6 (the latest edition). While being hindered by a lack of documentation and examples with regard to charting, i.e. the main way you view all the data in your system, I've had to reverse engineer the system that is being used. This would appear to be common in various areas of CE, i.e. it's entry point bait that gets you going on a project - then you realise you need Pro or Enterprise - to deliv

I've always been interested not only in the specifics of software itself, but also  in the method of how software is created, and what surrounds it. That being teams, leadership, management, external factors, business constraints and likely most importantly the sociology and psychology of creation . More of a holistic systems view of the whole process I believe.  My degree and area of interest is Software Engineering Management so some of the how as well as the what. I realised I've found myself explaining the same topic repeatedly to people in a business context (i.e. suits) who don't develop software, but who interact with people who do. So I thought it best to just write it up, then I can direct future people I encounter who ask or need to understand it to here. Also share my thoughts and hope to elicit ideas and experience from others, as this topic really interests me. The topic is that of the psychology of a developer, when operating a maximum capacity (relat

I recently saw a few tweets pushing a piece entitled : When Smart People are Bad Employees. Luckily the sense of many comments shone though, and the author was eviscerated for what appeared to be short sightedness, poor understanding of behaviour and basically poor posting. Though it did get me thinking about the amount of confusion and reactionary behaviour there is out there by this kind of management, which that author appears to be representative off (thankfully small and diminishing in my experience, though still present). Another case of trying to enforce "us and them" I'm right your wrong, opposed to "we". We're all human, and we're all fallible at times. I found the majority of this kind of behaviour and approach comes from a lack of trust, of oneself mostly, and then the team. A fear response to attempt to control, opposed to having the will power and self control to resist such behaviour. (There was another piece I saw on : Managin