There is no doubt: The environment in which software is designed, produced and maintained has fundamental impact on what comes out below the bottom line for all players playing in this game. I have learnt that there is little in software development, you can do intuitively right the first time – even if you have a background from another production discipline. Surprisingly even people working in a software development environment sometimes just don’t have the required understanding nor are they open to it.
To make these points of un-openness transparent, a great way is to talk about common myths around software development. Other people have done this before, so all I deliver here is a list of links that I can recommend for reading and discussion among your team:
Now check yourself: How much cynicism did you feel reading things like ‘More developers mean faster development’ or ‘Every design decision is documented before it is implemented’ or ‘You dont need developers when designing software’ or ‘The answer to every challenge we face in the software industry lies in doing more work in shorter times’ etc?
If you did not feel any cynicism at all or very little, well… it is time to leave the cave.
Sometimes you come accross something and pause thinking ‘I have experienced exactly that’. So it happend when I read Scott Ambler’s post ‘Bureaucracy Isn’t Discipline’.
Here are the main points and in my view ammunition for philosophical discussions:
- Successful agile practices demand great discipline and require significant skill and experience to actually get stuff done.
- Just following repeatable processes rather than focusing on repeatable results are ‘process smells’ and seen as anti-pattern.
- Delivering repeatable results in agile environments is critical to success in IT projects.
- Mistaking bureaucracy for discipline is a reflection of cultural damage that has occurred over the years to large organizations.
- This bureaucracy is seen as inhibitor to software process improvement efforts and particularly to agile methodologies.
- A cultural shift towards agile will make many ‘bureaucrats’ uncomfortable.
I think, the approach to use a defined set of formal processes (bureaucracy) comes from the management people who hope to reduce risk and thus ensure repeatable production results. On the other side there are the natural constants of the IT environment with its complexity, constant evolution on all layers, life-cycles etc.
In my opinion, a possible solution could be found between these two extreme views if…
- hierarchies are kept flat or are at least perceived as being flat.
- communication-paths are reduced to the least required number and everybody knows what exactly his job is and what skillset this requires.
- an open, friendly, frictionless and goal-oriented culture gets established and maintained (preferably top-down).
- the system allows the players to focus on and finish their tasks and have a feeling of accomplishment.
I have just discovered an issue if you store serialized objects into MySql.
At first I used fieldtype TEXT. If in this case somebody edited another field of such a record with phpMyAdmin and pushed the save button, the stored object in that record got currupted and the object could not be deserialized and instanciated anymore.
We now use the fieldtype BLOB instead, so phpMyAdmin does not give you the chance to edit the fieldcontent. And it works.
I have an individual CMS running for a customer, who can edit his events, news etc. in a typical admin area. Each of the items had an expiry date. On any call to a deep URL to one of the expired items (e.g. from Google search results) it would make a redirect to the custom 404-page like this:
The 404-Page itself would then respond with its own 404 header and display a beautiful error page.
As I found out, this would NOT have the effect that I expected it to have, namely that the next Google bot crawling these URLs would kill the URL from the index since it ended up on a proper 404 page via the redirect. The headers in sequence with the above redirect look like this:
GET /pages/events.php?id=123 HTTP/1.1
HTTP/1.x 302 Found
HTTP/1.1 HTTP/1.x 404 Not Found
But wait, there is 302. To verify this for your own redirects, you can use the Firefox add-on Live HTTP Headers.
The problem here is the use of a default redirect, which uses a status code ’302 Found’. This equals the old ’307 Temporary Redirect’ and has the meaning for the bot, something hast just temporarily moved. In order to ‘tell’ the bot that this page should no longer be indexed and deleted, you must use a ’301 Moved Permanently’ and you do it like this:
header("HTTP/1.1 301 Moved Permanently");
If you’re interested in the HTTP status codes, you can find the RFCs here.
After all of your redirects that should ‘tell’ bots to remove URLs from the search index use the 301 variant, you can then use the Google Remove Tool to speed things up and call the bot.
Here are the thoughts taken from a lecture of Judy Estrin (CEO of JLABS, LLC) on innovation recorded in October 2008 at Stanford University:
Core Values of Innovation:
- Curiosity and ability to frame open questions. Instead of ‘Do you need this feature?’ you could ask ‘What are you currently working on?’ or ‘What are your problems?’.
- Self-assessment, ability to question yourself about the direction you are heading and make adjustments along the way.
- Risk-taking and willingness to fail. Try something and accept potential failure in order to take lessons from it. If failure is a problem, nobody will try anything.
- Openess to share knowledge and thoughts. Be open to surprises.
- Patience to let things grow. Mutual trust among the team members.
Judy underlines, that it is important to address all of these points and find/grow the right balance in your environment.
Other interesting Points from the lecture:
- Maximize the potential for innovation in your team by hiring cognitive diverse people.
- Importance of attitude in people you hire.
- Support an encouraging culture in your team.
- People are naturally innovative (kids). This gets beaten out and is unlearnt by the system (school, university, incentive systems).
- Innovation is not necessarily a new product.
- Companies are making themselves efficient by measuring many business aspects. This limits them to incremental innovation, which is always based on prior work. Groundbreaking (disruptive) innovations are created in different environments.
Listen to the 60min lecture: http://ecorner.stanford.edu/authorMaterialInfo.html?mid=2052