Archive for May 2008
Those modern browser are nice and can do a lot of things. But there is nothing that comes close to a real desktop application, which is not restricted to the browser’s sandbox, by default has a rich user interface and can take advance of all the capabilities the hardware it runs on has to offer. A browser is just another form of an all-purpose terminal application. It’s like a VT100 terminal app – just with graphics ;-) And VT100 was introduced in 1978. Of course you can pick you favorite terminal type for comparision. There have been plenty of them – just as browser rendering engines.
Update: Here is another post with the same notion.
Imagine this. You develop some software that
- solves the business problem
- development time is short
- future maintenance is easy
- changes can be done quickly and safely
Still you are being told “It doesn’t matter whether it works” followed by “It is more important that it adheres to IT governance standards”.
I’m pretty sure that only the naive mind of a passionate software developer will find that confusing. Certainly there must be more elevated minds who can really understand the wisdom behind such rationale.
So let’s try the ridiculous attempt as a mere mortal and try to explore this further. Maybe we can get closer to understanding it. Probably the first thing to look at would be “IT governance”. What is that?
Here is a quote from Wikipedia:
Information Technology Governance, IT Governance or ICT (Information & Communications Technology) Governance, is a subset discipline of Corporate Governance focused on information technology (IT) systems and their performance and risk management. The rising interest in IT governance is partly due to compliance initiatives (e.g. Sarbanes-Oxley (USA) and Basel II (Europe)), as well as the acknowledgment that IT projects can easily get out of control and profoundly affect the performance of an organization.
To me it is a bit hard to see the relationship between software development and IT governance. Yes, the citation mentions IT projects, but I would like to think that those projects are not software development projects, but projects such as setting up new networking infrastructure, building a new data center or maybe switching from release X to release Y of any software product. Those things need governance, because they need to be done in a consistent fashion and risk and the impact of errors on the business need to be managed.
When you develop a new software product, then governance is probably not the right approach at all. After all you are developing something, which means that you have to figure out a solution to a given problem and you can’t possibly follow a certain pattern in doing so.
Now let’s assume for a moment you find yourself in an organization where you are tasked with the development of a new web application that should save a significant amount of revenue for the business, hit the market before competitors do it, or maybe open a new market. It is the year 2008 and you know the pros and cons of several Java web frameworks. Your stakeholders expect a modern, almost desktop-like behavior – what’s usually called a web 2.0 experience -, and you want to develop fast, because much is at stake. Further you know that stakeholders can change their mind quickly – that’s not their fault, they simply react to market forces – and you want to be able to give them what they need in time.
Sounds good – doesn’t it? So you experiment a bit and choose the framework and other tools that allow you to develop fast, cover all levels of the application easily with unit tests and you are willing to do some automated QA using Selenium. Then you go ahead and do a spike of some portion of the new system and you find that you can do this much faster than with older technologies. There has been some progress in the area of web frameworks and other web related technologies between the first servlets and today’s tools.
So you do this spike and demo the results. And you get the answer that it is more important to adhere to IT governance standards than that the new product works.
Does it make sense for a company to restrict developers of new software products to outdated technologies? Isn’t the prevailing meta everywhere faster time to market? What about maintenance costs? Why ignore software technologies that allow to build something that’s easier to extend and maintain? The counter argument will usually be that the company needs to be able to find developers who know the technology. COBOL was big in the past. Today it is not easy to find people who can maintain COBOL code. But it is possible to train people on new technology, which can be considered a smart move, because constant training of a company’s workforce ensures it is able to compete better with others.
Or maybe preserving a status quo by enforcing IT standards creates better products faster and I simply don’t get it.
A while back when I expressed by concerns about a particular team room I got some negative reactions including from one of the persons who working that particular room. My assertion was that I wouldn’t be able to concentrate in such a crammed room.
Now I’ve come across a few more pictures and I’d like to share the location of pictures of a team space that I really like: it’s on Brad Wilson’s blog.
Now that our Savila team has grown to 3 fulltime members plus myself I think I should post a few pictures myself as well. So watch out for them ;-)
I almost forgot. Have a look at entry #11 (Cadenza). I guess the plants not only give the room a special atmosphere but also help to dampen noise.
It is travel day and I have some extra time to catch up on my RSS feeds. On InfoQ I came across this:
InfoQ Personalized Feed for Stephan Schwab in Does Sustainable Pace mean a 40 hour week?:
Sustainable Pace is a well known XP practice however, different people relate to it in different ways. Could an Agile team increase its sustainable pace by working longer? An interesting discussion on the Scrum Development group tries to debate the correlation between the number of work hours per week and sustainable pace.
Interesting thought but probably completely futile and towards the wrong direction. Software Developers are not anywhere similar to machines because they are humans – not resources, as many misguided project managers, and probably many managers in general, perceive these talented people. You cannot increase the input and get more output.
On any team you need to leave room for learning. Without learning there is no improvement in productivity or quality or anything else. Skipping the learning means stagnation. In a profession such as software development stopping to learn is dangerous and will get the company and the individual developer into trouble in the near future.
So… Maybe the right question would be to ask how much time out of the regular work week should be devoted to learning, which is not related to the problem being solved in the current project. What the software development profession at large is in bitter need of is a much more elevated level of skills and knowledge and that includes developers and those who manage them.