Tag Archives: software development practices

Tip of the Day #18: Dealing with data rounding issues

If you have data coming in from a database, web service or other source external to your application and it contains, say for example, price information then do not round it. Don?t attempt to apply any form of formatting to it regardless of how much the client insists that the data will be in this form (e.g. all prices at go live will be in round pounds).

Yes, having whole rounded pounds, without having to display the pennies, on the front end looks nice and pretty. However, the display of whole rounded pounds on the front end is a rendering issue and should always be left to the code that is rendering the user interface. The rounding should never take place close to the point that the information is extracted from its source.

Why? Because eventually the client will want things displayed differently, to put prices with pennies in it, and you have to display those pennies. Now you don?t have to just update the rendering code to display the pounds and pence, but you also have to track down where that rounding occurs and stop it from happening in the first place.

But that?s not all. If you round data, effectively truncating it, early then subsequent calculations will be wrong. In fact, rounding isn?t just like truncating the data. Truncating is just removing precision. Rounding can change the value. That can cause even more havoc later on.

So, why round that early anyway, especially if the data is arriving in a certain way in the first place? Well, I can only guess that perhaps because back before anything went live, in the test system they weren’t. So, just to make the test system look like the eventual live system the prices were rounded the moment they arrived in the application just to be sure they were in round pounds.

The lesson, clients change their minds and business logic should always operate on the cleanest data, unsullied by rendering constraints wherever possible. This means that calculations based on that data will remain correct, even if other factors change.

Follow up on what not to develop

Back in May I wrote about a substandard website I attempted to use in an article entitled “What not to Develop”. I also sent the hotel an email at the same time telling them of the failing of their website, however, I never got a response.

When the post went live initially, I got asked on twitter to name and shame the company in question. I suppose publically decrying a company has the effect that if people start doing that then companies will be pressurised in to providing a better service or product. These days I do not to put in a blog post the name of the company in question until I’ve given them a chance to respond to any email I might have sent. I sent the email on 16 May 2009 at 17:21 (BST), I think that’s quite enough time for a response.

I’ve decided to publish some more details so that people can at least learn from the mistake and not repeat them elsewhere. Essentially, this is an extract of the email (slightly reformatted to fit this blog)

Hello,

I tried to book on your website last night and it didn’t work – it advertised a rate to me then refused to book it. I then tried to use your Contact Us page to send you a message and that also broke and said “The web site you are accessing has experienced an unexpected error. Please contact the website administrator. ”

I don’t know who the web site administrator is, but I can guess it is someone employed by TIG Global given this news story: http://www.hospitalitynet.org/news/4036652.search. Personally, if that is the quality they are delivering I wouldn’t use them again as they are not very good and are at best turning away potential customers and at worst exposing you to needless risk.

In order to [help you to] track down the errors I’ve gone back and replicated the initial problem annotating the pages as I go. You will find a number of graphics files attached.

Southwark Rose Hotel Step 1

In [the above image] I show the initial details of my availability search. Check in Friday 31st July, check out Sunday 2nd Aug. 1 adult, 0 children.

Southwark Rose Hotel Step 2

In [the above image] I show the next page. This was a pop-up, so opened a new window. The details at the top are correct and match what I’d previously entered. The description of the “Weekend Advanced Purchase” sounds perfect “Valid Friday-Sunday throughout 2009”. I see that it is £150 for the “Total price of the stay”. I press the book button.

Southwark Rose Hotel Step 3

In [the above image] I show the next page. This was another pop-up, so opened a second window. I now have 3 windows open just for your hotel. (Is this really necessary?). I spot that the number of nights has increased to 3, so I go to change it back to two. I then get an unhelpfully terse error message that says “Minimum stay: 3” [See the next image]

Southwark Rose Hotel Step 3 error

At this point I’m some what irritated by the experience so go hunting for your contact us page. I see that it is a form only without an email address. I fill in the form and when I’m ready I press the “Submit” button. At this point I get an error page back that includes the message “The following information is meant for the website developer for debugging purposes.” You might want to tell those developers that this information is also useful for attackers and they shouldn’t be displaying it to the public. If the developers were any good what they would have done is get the website to log the information internally and display a general message to the user. If they wanted to tie up a user’s experiences with what is in the log then they might also include a randomly generated (say a GUID – globally unique identifier) identifier that is put in the log and displayed so a user can refer to when explaining what problems they were having at the time.

The error message that should have never been displayed is [as follows].

Vomiting SQL for no good reason

The details in the error page also contain my original complaint. I think I now understand where the American formatting of culture specific information (e.g. dates) is coming from.The company that produced your website was American and in their arrogance just assumed everyone else was just as comfortable using MONTH/DAY/year. I suspect that same arrogance was also responsible for the other failings I’ve pointed out here.

Regards,

Colin.

So, there you are. The hotel is the Southwark Rose Hotel, and their website was produced by TIG Global. (I’ve recently noticed it actually says that at the bottom of the web pages and I need not have searched for relevant press releases!). Incidentally, you can click on any of the graphics to be taken to my Flickr account to see the full sized version.

Open Source Risk Management

Open Source Initiative Logo There are some pretty cool things happening in the open source space on the .NET platform these days and new projects are being started every day. However how do you sort the wheat from the chaff? How do you manage risk when using open source?

In this post I hope to address this issue as it relates specifically to open source frameworks that target .NET. Although I am sure the ideas are probably equally applicable to other forms of open source, I don’t have much experience outside of this field so I can’t really comment.

I have a some fairly simple rules when it comes to open source frameworks and perhaps they show me as being somewhat conservative but it works for me. I see that as trying to manage risks as effectively as I can. These rules are:

  • It must have a “buzz” surrounding it.
  • It must have reached at least version 1
  • It must have at the very least prebuilt libraries/assemblies/executables (as needed)

The “Buzz”

The first rule is that there must be a “buzz” surrounding it. By “buzz” what I really mean is that there is a viable community of people who are using the open source software so that if I need support there will be forums or discussion groups that I can join and ask my questions. This community will also have produced good quality documentation, tutorials, articles, blog posts, and so on.

When I start using a some open source framework I want to be able to ramp up quickly and get using it. I want to see that there is MSDN style documentation for when I need to dig into individual methods, properties and the like. I want to see that there are walk-throughs and tutorials so I can see immediately how everything fits together. If there are videos available they need to be good quality because it is really off putting to try and read source code on a video that’s been over-compressed. Podcasts discussing the high level stuff can be useful, but it has to be of the type that I can easily listen to in the car or while walking down the street because I will rarely listen to a podcast while sat at my PC.

A good open source project will also have fairly active support forums with questions being answered from those that understand the technology. It is interesting that lack of “support” is what many people claim as being one of the big risks with open source. However, how many times have you called Microsoft for support? (assuming you are developing on the Microsoft platform) In the last 14 years I’ve phoned them exactly once. Meanwhile, I’ve used newsgroups and support forums more times than I care to remember. The response from forums is usually quite good and well within the length of time I would generally wish.

However, not everything is rosy with forums, open source or otherwise. A couple of years ago I saw a forum dealing with an open source project where the main (possibly only) developer was an arrogant arse in response to any request for help. His standard response was “read the code”. That was it, end of discussion. There didn’t seem to be that many other people using his library so perhaps he put many people off. If this were a commercial operation, that person would have been removed as a support engineer for fear of losing sales. Then again, how many times do you hear of companies with poor after-sales support.

Incidentally, I’ve heard the response “just read the code” or “read the unit tests” from a number of open source advocates. That is one way to turn me away from the project. I really don’t have time to read the code when I’m evaluating a number of frameworks that do similar things. I want to see if the framework will do the job I want it to do. If it doesn’t do what I want it to do I want a quick easy way to short circuit the evaluation.

Don’t get me wrong here. I am not saying I never read the code. It can be extremely useful to read the code when tracking down a bug somewhere and you need to see what the framework is actually doing. What I’m saying is that it should not be the only source of documentation. I will often get around to reading some of the code before fully committing to the open source framework.

Release Version

The second rule is that it must have reached at least version 1. I’m not interested in using betas, CTPs or nightly builds. There are very few things I will use prior to a release. (Curiously as I type this, I’m doing so on a pre-release version of Windows 7. The other thing I’ll use in a pre-release form is Visual Studio – both major products in an already fairly mature state. I’ve been using Windows since 1992 and Visual Studio since 1995.)

What a version number gives above all else is a point where the developers stick their flag in the ground that people can rally around. Without that I could end up having to use various nightly builds. While the nightly builds are great for the testers and developers on a software system, I don’t think they are good for those building upon the system.

For example, if I have an issue and I go to a forum dealing with the framework I can very easily say I’m using, say, Version 2.1 and know that there will be a good number of people also using that version. If however I go along and say I’m using nightly build 518 then I might find that there are very few other people using that specific nightly build and that any potential solutions to my problem by people using other nightly builds may not be able to take into account some weird quirk that only happened in that specific nightly build.

The “standard” response would likely be to download the latest nightly build and use that. However, I see that as adding extra risk into my project. Apart from anything else I would now have to retest all the places where that new nightly build is being used. Sure, unit tests can help at this stage, but integration tests still need to be run, end-to-end testing, user testing and so on.

One of the advantages of open source is its speedy resolution and it may sound that my strategy here is negating that effort. I don’t believe that is so.

When a project has milestones and release goals the development gets to a point where all the features are there and the public interface has solidified although there may still be some bugs. At this point betas are released and a wider audience can evaluate the framework, report bugs, and generally give it a much more thorough testing that the core development team could do. By the time the framework is RTM’ed (although RTW maybe more appropriate in this internet age) the major bugs will have been worked out.

Once a release has been made even more people will start using it, so some of the more esoteric bugs will be found and a service release will likely become available shortly afterwards that rolls up a number of bug fixes. This is still a lot faster than most commercial offerings.

Pre-built Assemblies

The third rule is that the assemblies must already be built in advance. I don’t want the hassle of building these myself. The process is too prone to error in my opinion.

If I build the assemblies then there are risks based on the way my machine may be set up. I’ve seen systems where the build process is quite flake to begin with and I simply don’t want to add to that. I also don’t want to waste lots of time  having to faff about with a build process trying to get it to work as it can easily eat up a lot of time.

Incidentally, I may concede this point once The Horn Package Management Project reaches some level of maturity. However, it looks like it may be more useful for those developing complimentary open source projects to keep up with each other rather than someone like me.

Where’s the risk?

As I said at the start, I’m probably fairly conservative when it comes to using open source. I want to see that others are getting benefits and that the major bugs have been ironed out. Yet, I have no real concerns about using open source projects that are clearly maturing or are mature. In that scenario the risk is fairly minimal, and probably a lot less than using an equivalent commercial offering – After all, you still have the source code if the project stops, what do you have if the company fails?

 

 

CC-Attribution:

  • OSI Logo by Ken Coar (June 10th, 2009)

What not to develop

I was recently looking to book a hotel in Southwark in London. I thought I’d found the perfect hotel, it was inexpensive (by London standards) and close to where I would be visiting. They also had availability on an offer for £75 per night, so long as you checked in and out on specific days, which I happened to be doing. It looked perfect.

But then things started to go wrong.

I selected the rate from the availability page and clicked the “Book” button. The next page popped up (it opened a new window) and the details were pre-populated. However, it had changed the number of nights from 2 to 3. I didn’t want 3 nights, so I changed it back to 2 and I got a rather terse message saying “Minimum Stay: 3”. I’m happy to accept that style of message from a compiler, but not from a public facing website.

I went back and repeated the process wondering if I’d somehow clicked on the wrong rate. I double checked everything this time. Date is correct (but in an American format on a .co.uk website), number of people (1), number of nights (2), number of rooms (1), the room description explicitly gives the rules for the stay conditions for the rate. I meet all the conditions that are presented to me. I press “Book” again…

And it has pre-populated everything again and added an extra night on. I don’t want an extra night! Why even present me with a rate that I can’t have because it doesn’t meet my needs.

By this point I’m more than a wee bit frustrated. So I take off to the website’s contact us page. Instead of providing an email address there is a form to fill in. So, I write a description of the issues I was seeing on their site at which point the site fails again. It failed spectacularly badly. If it had taken me to an error page I would have just shrugged my shoulders and gone off elsewhere. But no, it decided to throw up its internals at me. It vomited details of the SQL Statement that failed, stack traces and so on.

It even had the audacity to tell me that “The following information is meant for the website developer for debugging purposes.” It might have well have said “The following information is meant for an attacker so they can destroy our server.”

So, back to my title, what not to develop. There were many failings on this website that I could see. The user experience was poor to start with and it then descended in to abject failure when it vomited its guts up at me.

1. Don’t use pop-up windows; browsers may block them; they cause confusion for some users. Absolutely do not have a pop-up out of a pop-up; it clutters my screen with needless windows.

2. Don’t have a disconnect between the display locale on the site and the TLD. If you have a geographic TLD then display information in a way that consistent with the culture of that location. e.g. Do not display dates in Month/Day/Year format when you are serving pages on a .co.uk domain. If you have customers from overseas and want to localise content for them then offer that ability, but default to your own locale if you don’t know their preference. Some websites try to be clever and will detect based on the IP of the user but even this isn’t 100% accurate. I’m located in Glasgow, but if you use a IP geo location service it shows me in Greater Manchester.

3. If a user has told you their needs do not present rates that do not meet those needs. If you do want to show near alternatives then make it clear that the details entered do not match the rate displayed, but some minor changes will get the user the rate. Put this information at the bottom or in a different colour. Anything that makes it easily distinguishable.

4. Don’t allow a business rule to mismatch the user friendly description. Make sure that the description of the rate actually matches the business rules that will be used to enforce the rate. If you have a rate that is described to the user as from X to Y don’t have the underlying business rules enforce a stay from X to Z. That will just irritate people.

5. Don’t give users terse error messages; it is unpleasant and unfriendly. If a user has made a mistake then gently point it out.

6. Don’t just send data to the database without validating it first. If a user has typed something that is too long for the column in the database for which it is destined then the software controlling the website should never have attempted to send it to the database in the first place.

7. Don’t display information that could be useful to an attacker. Don’t display stack traces, SQL Statements, system generated error messages, code snippets, etc.

Rant of the day: Learn to frickin' count!

I was in a shop recently and I bought 6 items at £5 each. A total price of £30, even I can manage that mental arithmetic without resorting to a calculator. However, the till decided that the total price was £30.01. For a penny I really can’t be bothered to argue, but it got me thinking about code quality and wondering about what awfulness must be sitting in that system to create such a simple basic mistake.

My colleagues are probably all aware of my views on code quality. I rant daily whenever I see examples on ineptitude by people that are paid money to write code. I read and respond on forums in order to help others learn their craft, or just get unstuck when they accidentally dig themselves in a hole. However, I see on an almost daily basis these days people posting their homework questions with no apparent attempt to at least try to work it out from themselves.

Take this example I found on Code Project a while ago:

I need to know how to do some simple things with arrays please help with any!
1.Find largest or smallest value
2.Count how many times a given value is in the array
3.Count the number of even or odd integers in the array
4.Add up the sum and compute the mean
5.Create another array of the same size containing the same values in reverse order
Thanks!

This is very obviously an exercise from an introductory course on the language they were studying. They just want someone to give them an answer that they can copy and paste. If this is what they are like now, imagine what they will be like years down the road writing commercial software.

I’ve seen lots of evidence over the years of people writing software by copy and pasting examples from the internet without thought of what is actually going on. This results in slow, bloated, inefficient code that is integrated very badly with the rest of the system, hard to read, hard to debug, and is just generally a complete mess.

If you are tempted to copy and paste some code snippet from the internet for your application then stop and think first. Do you actually understand the code? If not, then don’t copy and paste it. If you don’t understand it, how will you debug it?

I would say that if you are tempted to copy and paste from the internet that you create a very small test application first, paste it in to that and learn how it works. Once you understand how it all fits together and how it works you can then write a version that will integrate in to your application.

While you are at it, write some unit tests to go with it. Make sure you test for edge cases, make sure you test for some normal cases too. If you ever get a bug, then add a test that replicates the bug. So if someone suddenly discovers your software things that 5 times 6 equals 30.01 you can add a test for it, fix the bug and redeploy the system. Hopefully, this would have been caught before the public get a chance to see the glaring error and write blog posts about it.

Developing with SQL Server 2008, deploying on SQL Server 2005

I received the following by email today:

Hi Colin! I found your blog after googling for a bit about SQL Server. I had a question for you… As someone fairly new to .NET development, would it be easier to stick with SQL Server 2005 for now, or just install SQL Server 2008 express? I ask because I don’t yet know enough about the differences between the two to know if there will be any issues when developing small web applications with 2008, but then deploying them to a hosting provider with 2005. Hope that makes sense. 🙂

Cheers,
Sean

I don’t recommend moving to SQL Server 2008 if you will ultimately be deploying on SQL Server 2005.

If you don’t know the difference between SQL Server 2005 and 2008, yet your hosting provider only supports 2005 then you would be better off sticking to working with SQL Server 2005 on your system. The reason for this is that you don’t want to accidentally stumble into features of 2008 that are not supported on 2005.

Also, even if you were intimately aware of the differences between the two versions it is still a good rule of thumb to develop on a system that is as close to the eventual live system as you can. That way you won’t get any unexpected nasty surprises when you do deploy the application and suddenly realise that things are not quite as expected.

If you have already developed the applications then you can set the compatibility level of the database to mimic SQL Server 2005:

ALTER DATABASE [MyDatabaseName] SET COMPATIBILITY_LEVEL = 90

That way you should have a similar (although not necessarily quite the same) experience as if you were developing on a real SQL Server 2005 system. There will still be things that you cannot do. I don’t think backing up your 2008 database and restoring it on a 2005 system will work.

Code Reviews

I’ve been meaning to blog about code reviews for a while, but I’ve never seemed to sit down and organise my thoughts on the matter. Well, I’ve got some time now, so I’ll do my best to organise my thoughts.

First things first – Code Reviews are, in my opinion, not a “nice to have”. They are an essential part of the quality control for software. Anyone that says they are a “nice to have” simply doesn’t understand the ancillary benefits of doing a code review besides ensuring everyone is keeping to the same style. In fact, keeping everyone to the same style is to my mind a pretty minor part of code reviews.

Whose code should be reviewed? Everyone that writes code should have it reviewed. From the gap year students up to the senior architects (if they still write code). There is no level where you say “That person is senior enough to review their own code”. I am a fairly senior developer and I am not so arrogant to think that I won’t benefit from code reviews.

Who should conduct code reviews? Everyone should conduct a review. Now, obviously the graduate developer isn’t going to pick up on things that a senior developer might, so this is more of an opportunity for the graduate to read someone else’s code. They will, hopefully, learn more from reading a senior developer’s code than they will find fault with it. It affords them the opportunity to ask questions regarding why things were done in a certain way. And often a graduate will bring a fresh perspective to things by suggesting new techniques that the senior developer may not have had time to read up on yet, but which the graduate recently learned at university.

For pretty much everyone on the team, conducting a code review means looking through and understanding code in parts of the system they may not have the opportunity to see otherwise. This means that the developers on the team will have a greater understanding of the overall system. Maintenance, once the system is live, becomes easier to manage because all the developers that worked on the system should know enough about all its parts to be easily assignable to the task. Management doesn’t have to pull a specific person off another project and if a developer moves on there is still retention of knowledge about the code in the company.

If code reviews are conducted frequently it gives the reviewer a chance to ask the developer about design decisions while there are still fresh in their memory. The reviewer can potentially learn about new techniques, or potentially head off future problems if the decision was incorrect.

Code reviews are difficult when developers’ egos become involved. It is therefore vitally important that reviews are constructive. It is not sufficient to point out where something is wrong, but to suggest a way to improve it as well. As was mentioned earlier, the reviewer should find out why the code was written in a particular way. The developer may have a valid reason that the reviewer was not previously aware of. It is better to find that out first before criticising the developer for seemingly poor code. That said, it is important to find out what alternatives they considered and why they think their ultimate decision was correct.

Positive aspects in the code must be found also. If a developer constantly receives poor code reviews they may become protective of their code and refuse to submit it for review, or otherwise indiscriminately attack other developers on the team or management rather than seek to address the problems that exist. If the developer under review is junior they will most likely deliver poor code to start with. With each code review comment on areas that they have improved on so they know that they are getting better as it is often the case that as one area in need of improvement is resolved other areas become apparent.

It is also crucially important that reviews are frequent so that problems do not build up. The worst thing is for problems to have built up over a number of months and for a developer to only find out about it during their annual review. This will lead to resentment.

In short, everyone’s code gets reviewed, and it gets reviewed often.

Tags:

Speed Kills

Speed Kills not just on the road, but in software development too. If you don’t believe me then just ask Uncle Bob[^].

I remember years ago I was crazy like that. “Gotta get this done, gotta get this out the door.” I was working until all hours of the night, heck I even worked on Christmas day cranking out code. Eventually the sales guys said, “we need this feature or this prospect won’t buy, and if they buy they’ll buy big.”  But…. “The feature is going to take months to implement. The code is a mess.”

Why would anyone code like that? Well, in my first job the schedules were somewhat unrealistic, moreover the scope was constantly changing. Being fresh out of university I had no idea how to estimate properly so I went with the premise that these people have been “out there” 10 to 30 years longer than I have. Also, I was a little too eager to please. With hindsight I can see that my gut feelings were right, but at the time any argument was met with somewhat patronising responses that I was still a “boy” and didn’t know how the “real world” worked. Eventually, I did manage to push through process changes to, at least, formalise things a little better, but by that point most of the damage was done.

What I can be thankful for now is that I don’t have to work like that any more. Schedules are realistic, code is better formed – sometimes a little rushed in areas due to an impending deadline, but not to the overall detriment of the project.

Thanks to Abdel Saleh[^] for the link.

NOTE: This was rescued from the Wayback Machine. The original was dated Wednesday, 6th October, 2004.

Lean Software Development: An Agile Toolkit

Lean Software Development: An Agile Toolkit
by Mary Poppendieck and Tom Poppendieck
with Forewords by Jim Highsmith and Ken Schwaber

A review of sorts

The book defines a number of tools to assist you in implementing an agile approach to software development and uses a number of studies from both software development and manufacturing to get the points across.

On the whole the book is fairly easy to read and presents the ideas clearly with examples. However, in some areas I felt that the examples were too geared towards the manufacturing industry and not towards software development. This is, in itself, somewhat surprising as the authors have pointed out that you shouldn’t try and directly take a idea from one industry and apply it to software development without some element of thought. From the final page of the book comes a warranty that contains: “This warranty is invalid if practices are transferred directly from other discipline or domains without thinking, or if the principles of empower the team and build integrity in are ignored.” (p186)

The warranty quote above highlights two of the three areas that I feel are the most important. The other area was the “Contracts” tool. The remainder of this text are the things that I found most interesting, or provided one of those “a-ha!” moments as a realisation of how a new idea might make things work better occurred. Some of the things may seem obvious, but a gentle reminder of them is never bad.

Empowering the team means that everyone has a clearer idea of what is going on and, most importantly, why. It means that the team have access to the information to do their job rather than be hidden away from the client and given a point-by-point specification to work through. While it is easy to work through a point-by-point specification it does not allow the developer to highlight potential errors or conflicts if they don’t understand why the specification says what it does. There may be some missing information or an assumption may be wrong, or common sense doesn’t turn out to be as common as once thought.

Another point raised by the chapter on empowering the team was that “software development cannot be successful without disciplined, motivated people”. Motivation is not only the key to keeping good employees, but also for keeping them energised. The authors give the example of 3M who, for over 75 years, have allowed the “entrepreneurial spirit to flourish” by permitting “small, self-organising groups that become passionate about a possibility and are allowed to make it a reality… Scientists are expected to spend 15% of their time on projects of their own choosing” (p104). Many of 3M’s new product lines comes from this. In the software development world the equivalent is Google, who permit their developers to experiment with new ideas which Google then bring to the market place. This is very successful. A current example is Google Suggestion.

Going hand-in-hand with motivation is purpose. People need to have a purpose, a set of goals to work towards. This manifests itself in understanding why the software is needed. If this sense of purpose is to prevail then beware of the sceptics. “Nothing kills a purpose faster than someone who knows it can’t be done and has plenty of good reasons why” (p106)

Building integrity in ensures that the customer stays happy (perceived integrity) because the software appears to work as expected without errors or problems and it also ensures that the developers stay happy (conceptual integrity) that the code base stays well ordered and easy to maintain.

For a software application to have perceived integrity (p127-134) it needs to be usable, reliable, economical, and it must function as expected. In terms of developing an application in this way domain models are built, which are models of the software that the customer understands. The authors go on to say that eventually the models created will fall into disuse, and that they should not be maintained just because it “seems like a good idea”

In terms of conceptual integrity (p135-149), the “system’s central concepts work together as a smooth, cohesive whole.” Specifically “particular attention should be paid to the presentation layer, since conceptual integrity in the interface design is a primary driver of perceived integrity”. In order to maintain the conceptual integrity the system must be simple (many software patterns aim to bring simplicity to complex designs), clear (so that everyone in the software development team can understand), suitable (so that it fits its purpose), D.R.Y (Don’t Repeat Yourself – removing duplication means that if something has to be changed it only needs changed in one place), with no extra features (“Anticipating the future is usually futile and consumes resources”)

Finally there is the Contracts section (p161-177). For me, this was the key to the whole book. For many areas in the book I was left wondering how this would ever work in an organisation that exists to service clients. For many of the concepts I could see how they could gain a hold inside a software product company, but not a software services company. They gave examples of the traditional time-and-materials and fixed-price contracts and how they don’t really work well. Then they presented three examples of contracts that would fit into the Agile development process.

NOTE: This was rescued from the Googe Cache. The original date was Saturday, 11th December, 2004.

Tags: