The technical laws of December

Throughout December I had the pleasure of collecting more or less clever statements about computers and software development in general. My twitter account  had a steady flow of these up until Christmas.

 

In today’s society, we have to use so much of our energy filtering out knowledge, and it is interesting how cleverly written sentences can capture so much information. I’m going to elaborate on several of them in the time to come, but for now, here they are again.

 

Disclaimer: These aren't my quotes - they've been collected from a variety of places and people, and thus credit is due in many places. I apologize for not quoting correctly.

 

Dec1 tech law: Walking on water and developing software to specification are easy as long as both are frozen

Dec2 tech law: In theory, there is no difference between theory and practice, but in practice there is

Dec3 tech law: Real programmers don't comment their code. If it was hard to write, it should be hard to understand

Dec4 tech law: Computers are unreliable, but humans are even more unreliable. Any system which depends on human reliability is unreliable.

Dec5 tech law: There is never time to do it right, but always time to do it over

Dec6 tech law: Adding manpower to a late software project makes it later

Dec7 tech law: The degree of technical competence is inversely proportional to the level of management.

Dec8 tech law: The probability of bugs appearing is directly proportional to the number and importance of people watching

Dec9 tech law: If a program is useful, it will have to be changed. If a program is useless, it will have to be documented.

Dec10 tech law: Good enough isn't good enough, unless there is a deadline

Dec11 tech law: An expert is someone brought in at the last minute to share the blame

Dec12 tech law: The chances of a program doing what it's supposed to do is inversely proportional to the num lines of code used to write it

Dec13 tech law: profanity is the one language all computer users know

Dec14 tech law: All's well that ends.

Dec15 tech law: No matter how hard you work, the boss will only appear when you access the Internet.

Dec16 tech law: A meeting is an event at which the minutes are kept and the hours are lost.

Dec17 tech law: An expert is one who knows more and more about less and less until he knows absolutely everything about nothing.

Dec 18 tech law: it's not a bug, it's an undocumented feature

Dec19 tech law: A complex system that works is invariably found to have evolved from a simple system that works

Dec20 tech law: The documented interfaces between standard software modules will have undocumented quirks

Dec21 tech law: Bugs will appear in one part of a working program when another 'unrelated' part is modified

Dec22 tech law: When designing a program to handle all possible dumb errors, nature creates a dumber user

Dec23 tech law: Build a system that even a fool can use and only a fool will want to use it

Dec24 tech law: The cleverness of  technical laws is inversely proportional to the number of laws

Walking on water and developing software to specification are easy as long as both are frozen

Developing software is pretty complex, but it’s not exactly rocket science, right? You find out what you want created, you get a number of software developers that has studied how the technicalities work, and after a time you end up with a good, working piece of software. Correct?

It's a shame how few reading this can actually agree with it. Why is that? And can anything be done about it? If you have a few decent developers (they don't have to be that good), a small set of requirements, a business expert they can discuss those requirements with... You know what - you just got yourself the perfect recipe for a good working system. Fingers crossed!

Unfortunately the previous description doesn't map to many real systems. One of the biggest problems is that requirements change. This affects all parts of software development, but no other part can influence the result of this like the process used. Back in the days, and still in practice quite a few places today, they tried to scale the previously described way of solving software development no matter the size of the project. You just collect and analyze all the requirements, find a number of developers to implement the system, get one or more architects based on some measure of experience to help design the structure, plan and discuss the requirements, implement it, test it and release it. That works to a certain extent, to a certain size, for certain organizations, but it has many limitations. I'm not going to try to cover those extensively now, but it includes

• You've got one shot at coming up with the features for the system. Now guess what happens -> You will try to come up with as much as humanly possible, important or not
• You have little idea how the system is actually going to look or feel or just how it can be used -> You will try to make the requirements cover everything. This isn't really a bad thing, but can be quite a complex process.
• Price the project beforehand, to move the risk of development to a software company -> Do you think those requirements change sessions will be fun?
• Your understanding of what the system can bring you, what you really need it to do, and just how it can do that the best -> Will change!

The whole point of this post has become very well understood in the industry - requirements change, and you'll have to cope with that one way or another. If you want a useful system that is. A number of smart people put their heads together back in 2001 and came up with the "Manifesto for Agile Software Development", and a number of principles behind it.

What was the cure they came up with? Besides a few other good points, it was the formalization of an old principle - tackle complexity by dividing a problem into smaller, manageable pieces. (Note: The original paper on the Waterfall model did cover the importance of a certain amount of iterative behavior, but I guess it was lost to quite a few people on the way.) If you’re trying to tackle all problems at once – or in other words not developing software in an iterative manner, make sure you have very good reasons for it. Unless the project is small, with clearly defined knowledge and boundaries, you’re going to have a hard time producing the system you really need. Do you do it for control? There is no real form of control  in software besides working software.

Is process the only thing you have to think about when handling change in software development? Not by a long shot, but it is an important part of it. I will cover more areas soon.

#GEEKBEER starting this Thursday (in Oslo)

Tore Vestues, Sverre Hundeide, myself and more thought it was about time we got a regular social developer-night together. The purpose is simply to socialize and have a good time.  No free beer, no surprises, just fellow developers/IT people.

 

We'll start up this Thursday (the 12) , 7pm, at Asylet (Grønland). Come along!

 

We hope to make it into a monthly thing, so don't despair if you can't make it this time.

Essential Project Practices: Communication and close customer collaboration

I'm a firm believer in the need for close customer collaboration in projects, a high degree of communication and continual status updates to best manage basically anything. I think I would define it as one of the major "make or break" characteristics of a project.

I remember being asked during an interview with my current employer what I believed was the biggest reasons projects fail. Communication was the big thing that came to mind. Projects fail for a myriad of reasons, but not the least because of a lack of communication between a number of involved parties. I thought I'd try to get in to a few of those aspects here.

Working on communication at all times is important. The various roles in a project or organization has different responsibilities here.

 

Upper management and project champion
First of all, any project, and especially those related to organizational changes, needs upper management support. If the project needs to communicate, integrate or in other ways depend on other parts of the organization, it is hard to do it without the support from the top. The unofficial networks built by social interaction within an organization are one way it can work.  But management support is extremely important, so you better find out how to get it - even if it is not your direct responsibility, pull some strings to find out if something can be done about it.

Another role of extreme importance is the project champion. A project champion is a person highly dedicated to see the project through from inception to success. Not completely about the topic, but this is a person that will help make sure that the needs of the project are taken care of throughout the organization. Communication is tool number one here.

Project manager -> developers
The project manager and the development group also need to communicate. I use project manager here to mean several possible positions, both project manager in the traditional meaning, and for instance product owners in Scrum tongue, or even in part Scrum masters. The two sides has different needs for communication. The project manager has the primary responsibility of delivering the project on time, within budget and according to specification. There's many ways of handling this.

 

Organizational requirements and processes is the primary one, but trust has no less importance.
Organizational requirements and processes is something you have to live with in some form. If you are able to build trust in what you deliver outside of the project scope as well, you'll most likely have more control of what you need to deliver. The major reason behind many of the demands and project artifacts found today is a lack of trust. The lack of trust is compensated for by putting in a myriad of artifacts, processes and control points. Even though that is often a false sense of security, I generally completely agree with the approach - if you don't have trust, the next best thing is to monitor the progress.

 

So how do you build trust? First and foremost you need to deliver (Hopefully on time, within budget, and according to specification :) ). Communication is tool number two. When problems arise they need to be communicated up the ladder as needed. If you have trust that problems once discovered will be taken through the right channels, you have a good basis for being able to solve any problem once they arise. To build trust, you need to communicate continuously. People are different, but little and often is often better than much and seldom. Manager Tools (brilliant podcast-series) has a podcast describing how humans relate to trust and relationships here.

 

Project -> Business expert and users
An essential step in delivering a product that fulfills needs is close collaboration with the business experts and users. It cannot be a single iteration waterfall-thing, it needs to be a continuous collaborative effort. You do something, then you verify what is done. You wonder about something, you contact the business expert or user. And how much easier is it to get both attention and clear answers if you have someone within the same room than over phone or email?

 

Developer -> Developer
Developers are certainly not excluded from the communication effort. Developers need to continuously communicate within the group to ensure everyone has a clear understanding of the problem at hand, to build project ownership, to share project knowledge, and to notify and get help for problems. And if you are a developer, what better way is there to increase your skill-set than to communicate with other developers? And try to be aware of groupthink, that is certainly not good to have to much of.

 

In conclusion
Writing about something like this is impossible to do well without references and ahead planning, so I'll easily admit that the above text is heavily flawed. However, the concept is very important, and that's why I wanted to share a few disconnected thoughts on it.

 

If you find the topic interesting it's not hard to find sources talking about it. It is slightly harder to find interesting sources.
The podcast mentioned above has interesting topics, but it is mostly related to managerial behaviours. You can access it here
If teams and communication is interesting, you'll find Peopleware's Productive Projects and Teams great.
If other aspects of communication seems interesting, I'll be happy to recommend books on the subject.

NNUG: Tonight's meeting

Jimmy Nilsson and Tore Vestues was the speakers on todays NNUG-meeting.

Jimmy Nilsson is most known for having written "Applying Domain Driven Design and Patterns", one of the few good books on DDD, as well as having a practical focus on for instance TDD. Jimmy was nice enough to speak for us tonight after having held a LEAP course today. I haven't heard him live before, but if you can say anything about Jimmy, besides being very skilled, is that he is a really nice guy to listen to. Good stuff :) For those that missed it, his speech "En ny era för dataåtkomst?" (A new era of data access) took on the history and general approaches about data access, as well as more general info about TDD. Please remind me that we must have a topic with a more close look at the data access options soon.

Tore Vestues had a speech about about Code Quality. (In the interest of full disclosure: we are colleagues.) The speech was well worth the time, and the topic should be on the absolute top of your list of priorities.

Interesting Old Stuff: Management tutorial

I  browsed through an old mailbox I used long ago today, and stumbled upon an old weekly tutorial for a project management class I attended.  That week's tutorial seems like it was about methodologies, continuous feedback and client demonstration. I know I would have a lot to say about that now :)

 

An interesting read out of a sort of sentimental fashion for me. I'll post it here just for fun

 

You are the IT project manager of an organisation developing innovative ‘leading-edge’ warehousing solutions. Although a number of individual software components have yet to be completed your clients are insisting on regular updates of your progress, backed up by demonstrations of the latest versions of the individual software components. Their insistence is being reinforced by the client’s threat to withhold staged payments that are required to be made as part of the contract terms.

 

How might this type of client behaviour affect the type of development methodology you employ?

With any project we believe it is important to supply the client with regular updates and demonstrations of the latest versions of the individual software components. When dealing with a very insistent client, as in this case, we believe that there is a need to use a methodology that incorporates user/client involvement throughout the project.

The development methodology type that is most suited for these requirements is one based on prototyping. By using such a methodology the project will focus on and deliver working prototypes, and show early efforts of integrating the different parts of the project. An example of a methodology that could be suitable for this type of project is Extreme Programming (XP). XP is a spiral type methodology with short iterations and close customer contact. It has a strong focus on integrating early and creating working prototypes. Since the customer will be updated on the progress of the project at short intervals and are able to change direction due to problems or new requirements they will be able to do real-time planning with the project.

Generally we believe that it is important to know and understand any development methodology, and not use any aspect of it without considering the consequences. Often you need to use parts of different methodologies, or change part of the one you are using, as it does not necessarily work perfect in your organisation.

 

Why do you believe the client might be so insistent on receiving regular ‘proof of progress’ updates?

There are many possible reasons for why a client would insist on receiving regular “proof of progress” updates. We believe that such an insistent client’s main reason for behaving like that is the risk of project failure. It is well known that many IT projects fail to complete at all, complete far over time or budget, or just isn’t used as planned in the organisation.

During a project there are many problems that occur. A client wants to see that everything is going as planned, that the project milestones are met, and that the contracted agreements are fulfilled.

If a project develops away from the project specifications and the project plan agreed upon with the client, then the client can demand corrections according to the contract or even bail out. The earlier this is discovered, the better it is for the client.

You discuss the issue with your own executive management and they make a suggestion that you merely ‘fake’ the demonstrations without making any genuine attempt to provide a genuine product. What are some of the implications here?

If you were to “fake” the demonstration of a product we believe that there can be both positive and negative implications to this.

Firstly, it might be positive for the project to do this if you are having a slow start to the project but you are still very confident that you will be able to finish the section in question on time.

Another reason might be if you are up to date on the coding, but you might still have problems showing visual proof of progress. By faking the demonstration you can avoid problems you might get by not producing visual results. In other words you will not be picking the low hanging fruits first just to have something to demonstrate.

On the other hand there are some negative implications too. You can risk giving the client false hopes about the probability of project success. If the client detects the faking of the demonstration you will have to take the consequences. This can range from the client loosing trust in you, a loss of reputation and a loss of the contract to possible lawsuits.

All of these negative implications are risks that can lead to economical consequences. Therefore it’s important that you consider the implications thoroughly before making a decision to fake such a presentation.

Interesting Blog Posts: NHibernate and Entity Framework Battle it Out in the Real World

If an OR-mapper is what you need, here's a short and interesting real life example of how a showdown between EF and NH went.

 

Note: Look, I am saying OR-mapper here, so don't get me started with the "they are impossible to compare since EF is supposed to be a persistence-, object-, view-, query-, dataservices"-discussion. That is so 2008.