Stephan Schwab - sdlc tag

It doesn't matter whether it works

Tue, 20 May 2008 04:10:10 GMT

Imagine this. You develop some software that

works
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.

Team room

Sat, 03 May 2008 20:32:06 GMT

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.

Does Sustainable Pace mean a 40 hour week?

Sat, 03 May 2008 20:08:22 GMT

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.

Some businesses should stay away from Agile

Mon, 21 Apr 2008 02:25:35 GMT

I'm pretty sure you know that very well ... I've spent today wandering around thinking about the topic of corporate IT and Agile. One of my thoughts were related to education and the type of person one wants to have on a team. I even started to write a blog post about it but stopped because its a broad topic and certainly needs more thinking to make sense.

But one thing seems to be clear. While the corporation views IT in a supportive function Agile might not work at all. They will always set a fixed deadline, a fixed budget and expect a full feature set. The fun part will always be that "full feature set" will never be clearly defined, because they just want "something that helps the business". And obviously there is no time to figure out what that is, because they have a business to run. ;-)

So unless "the business" understands that software development is always new product development with all the risks that come with it, those projects will always be in trouble. They would be better off to buy off the shelf software instead of attempting to develop their own.

When you develop a new product you usually don't make it a fixed-time, fixed-budget and fixed-scope project. You target a point in time (a trade show maybe) to release a first version or you have a budget and go as long as it lasts. Or you define the scope and accept that time and money needed to accomplish the task are unknown.

If you are a business and just want support from IT, then you should stay clear from any form of development. It certainly is far better to choose off the shelf software that can be customized. You then pay people to do specific work and that's basically what ERP systems like SAP R/3 offer. The good thing about this is that you can get people who are really qualified to do the job, because the way how such a system gets customized doesn't change so drastically as for example Java web frameworks or technology in general. It may be expensive, but it certainly is far more predictable than custom software development. It's kind of calling a carpenter or plumber - just a bit more advanced.

Psychological evaluation for Agile?

Sun, 20 Apr 2008 04:10:09 GMT

Based on a number of recent experiences I've come to think that there might be a relationship between work ethics, personal motivation and whether one will succeed with Agile projects. This post will definetely not give the answer. It is merely a thought I wish to publish and maybe some kind readers will provide their own opinion or share their own experience.

To me it seems that there are two types of people in software development. Those who are passionate about creating some work of art and enjoy building software. And those who simply work to make ends meet.

By no means I am condemming those who wish to make ends meet. That's only natural and in a world where one has to buy food, shelter and other supplies it is simply a matter of survival, if looked at closely. People do so many things to that end and I can only speculate why some of that type chose software development and not something else.

Let me make clear that the last sentences do not only refer to those who actually write code. I am talking about all the others who are involved in any software project as well. That includes persons who represent the business side and write specifications - user stories or in other form -, those who manage teams and individuals, those who work in QA, system administration and everything else.

It is astonishing to see what small teams comprised of passionate and highly motivated indiduals can accomplish when they are not restrained by any form of governance. I believe a team comprised of good "corporate citizens" would probably work for a year and still be disussing which toolset to use.

The question is why is that?

Maybe it is because there are so many choices that only someone who devotes his life to the art of software development is able to keep track and accumulate enough knowledge for making an informed decision. Can that be? The regular corporate office worker spends 8 hours at work. A good chunk of that time is used up by meetings, responding to emails, preparing reports and other administrative duties. When this person arrives at home she is tired and wants to be with her family. And the weekend is certainly not spent researching technology topics. I remember one 40ish gentlemen who was working in the IT department of a mid-sized company on SAP R/3 stuff by the time I met him. He was pretty interested in learning about network security and TCP/IP networking in general. So I referered him to a number of books and his response was something like "I have maybe 10 minutes per day to read when I come home".

The Agile Manifesto says:

We are uncovering better ways of developing software by doing it and helping others do it.

Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

That is very noble and makes a lot of sense. Unfortunately it does not mention anything about the type of individuals.

Can Agile work with people who are only interested in their paycheck, having fun in life and be home one time? Can it work with those who like it easy? Those who prefer to hold up anything with endless discussions about nuisances unconsciously knowing that it will allow to water down anything and get away with it?

Or is Agile merely something for the doers, self-motivated people who are interested in getting it done and then improve it further? Does it refer to entrepreneurs?

How hard is it to transform a worker type person into someone who is passionate about his work? Do we need a psychological evaluation of team members to determine whether they are suitable for Agile?

Update: After posting I did a Google search on psychological evaluation Agile. I would not have expected the result. Interesting...

The connection between accounting and sub-standard tools for developers

Sat, 05 Apr 2008 18:16:30 GMT

First of all I have to say that I'm really surprised by the feedback I'm getting. The post What's wrong with software development in large corporations has been the most read post on my blog ever. More than 3,000 people read it on the first day alone.

The other night when I wrote the post I could have gone on for a while. I didn't because it would have been far too much. So allow me to add a few things in this second installment.

Electricians with only a screwdriver and no other tools

Would you accept an electrician who shows up at your house with only a screwdriver in his hand? You probably expect such a professional to carry a number of specialized tools, some basic material and other things needed to perform the work - wouldn't you?

Well, I can report that one and a half year back we had exactly that happen to us in Panama City, Panama. We had some very strange things going on with the electric installation in our rental apartment (current on wires that should have none) and the administrator of the building called an electrician. After a three hours wait a man in his fourties arrived by taxi and from his bulky pants he pulled a single big screwdriver as his only tool. He then started to loosen and tighten some screws holding wires in place and never managed to solved the problem. I had the opportunity to see for myself a good part of the building's electrical wiring and I have to say that it looked to me as it were at least 50 years old. You can imagine that I was quite surprised when they told me the installation were only 10 years old. The explanation was that, yes, the materials used were taken from another building that has been torn down.

Now you might say that you can understand that because it's Latin America, Panama were a third-world country, etc. I'm willing to accept that - to a certain extent.

The connection between accounting and sub-standard tools for developers

But how do you explain why companies of any size let software developers work with inadequate equipment? By inadequate I mean slow CPU, few memory and a small screen. Some would probably say that I'm a big sucker for screen real estate as I had a 21" monitor on my desk back in 1995. But on the other hand I always paid the same amount for my computers through all the years. There is this saying that a software developers needs a new system every year and a half and see that exactly corresponds to Moore's law. Every 18 months you get twice the power or can get the same for half the price.

Software development is expensive and it takes a while to get it right. The professionals who possess the knowledge and long-term experience charge a premium and to me it doesn't make sense to save a few Dollars or Euros on equipment. I don't want to start talking about salaries here, but I think it's safe to say that a high-end, state of the art workstation with the biggest screen you can get is still far less than a month's salary. The question is why do so many companies hire expensive developers or pay expensive consultants just to slow them down artificially by letting them work on 15" laptops with a locked-down Windows XP and as little as 512 MB of memory? With that kind of system you start eg. Eclipse and Firefox to try out the webapp you are supposed to develop and then have to plan ahead of time where you are going to click ... Could be seen as some elaborate form of torture ;-)

Looking a bit deeper one will find that budget constraints are usually to blame for that kind of nonsense. The project gets funded out of one department's budget and the hardware is usually already there or provided by a central services department. And the services department usually charges an outragous amount - although it's kind of a fictious charge, as it is only ledger adjustments - for sub-standard hardware. So it's not that the company doesn't have the money. It is simply not available where it should be.

But that is only one part of the equation. In some cases one may want to ask why a department that is charged with software development doesn't have adequate hardware at all in the first place. I can't tell for sure how the taxation rules in the US are with regard to this, but in Germany the problem has always been that companies can only deduct expenses for new computers over a three years term. I remember it being five years and that has been reduced after a lot of controversy.

Actually it should not matter much how the taxation works. Software development is a big investment, the professionals doing it should be supported by the best tools money can buy in order to create the best software possible for the company they work for. So in the end it comes down to a leadership issue.

There are companies that get it

There are some companies that really get it. For example Matt Raible reports that LinkedIn is giving even contractors new MacBook Pros for their work and other companies buy their developers Macs with 30" screens at the workplace and at home. That truly expressed how they value and appreciate the work these highly skilled individuals are doing for them. Should be common but sadly it isn't.