2-dimensional project management and the strapped chicken

There are two aspects: how long do you have and how much do you want?

Now if the date is a “drop-dead” date then you can make it fit… Well that is, you can make something fit in the time by chopping the end off and saying “Now it’s complete because it ends there!”.

Then there is the “traditional” way of just overrunning until it is all done.

So what do you do if all the features are required AND the deadline is a “hard” one; for instance, the law is changing on the 1st April and if you aren’t ready then, well, someone is going to jail. Well, two things: make sure you aren’t going to be the one going to jail and secondly: you need to find a way to meet the features fit in the time box.

So, what do you do? Fake it, of course! Not really fake it, no point in just having a picture of the application… but don’t have time to write the GUI to input the data? Fine; just use a spreadsheet and some SQL. Don’t have time to validate the data validation framework? Check it manually. It needs to look like a real application of course; the concept is: strapped chicken, it does work, just only under certain circumstances. It won’t last, but then it doesn’t have to… As soon as you get past the deadline you have a whole other quarter to implement the real features.

Refactoring on rails

Is it rude to try and refactor someone’s code when they are working on their laptop on the train, and you are shoulder-surfing?

The guy next to me was cranking out vb6 and his function was well over 200 lines long and had 10 levels of indentation…

My God it’s full of stars…

Some people shouldn’t be allowed to run software projects. I’m all for close alignment with users and I’m all for recognising that program managers and project managers are special and useful people who aren’t either users or developers. However there are some people that just shouldn’t be allowed to be involved in making things. The problem that they don’t realise that to make something requires a human being to think clearly and concisely about every single detail of the thing, no matter how small, or it won’t exist.

Actually, they don’t even realise that there is anything “inside” a machine; whether that machine is a car or a website.

I used to date such a person. And let me point out she was extremely intelligent person. A 3.9 GPA at U.C. Berkeley so really very clever. However, two incidents made me realise that not everyone thinks like me. She had a mountain bike that she hated; always complaining about how heavy it was and how hard it was to ride. One day she lent it to someone else and when they gave it back she said “I don’t know what he did to it but it is SO much easier to pedal!”. I looked at her with my mouth open for a second and said “b.b.b.but.. he just changed gear!”. The blankness on her face convinced me to go easy on her. The she followed up with “..and the brakes are still terrible”. “Yes, the back brake blocks need replacing” I said. Again the blankness. “You do know that one brake handle does the front and one does the back, don’t you?” Now the look went to scornful; I was the dumbest she had ever met. “No, they do both at the same time.” I didn’t bother to explain about the obvious fact that only one cable went to each brake, I just advised her to try it. I don’t know if she even knew how to do that.

Remember, that person was NOT stupid. She just didn’t realise—had never even considered that – brakes didn’t just work the way she thought they did, they worked according to The Way Things Were. And The Way Things Were didn’t happen by accident or serendipity, they happened because someone looked very carefully at the problem and decided what to do.

The problem is that when such a person is setting the requirements for your project you are doomed. They can’t understand why the developers can’t make things as fast as they can brain fart them out. And when all the requirements can change in a day, the code can’t change in the same way. The only hope is to educate them or slay them. In the former, a serious attempt at domain-design might help, if you can get them to engage with it

The reason that we have so much bad code is we have too many computer scientists

A good scientist is a person with original ideas. A good engineer is a person who makes a design that works with as few original ideas as possible. There are no prima donnas in engineering.

Freeman Dyson

Programming isn’t science; there are no points for difficulty or being original just for the sake of it.

Aspire

The world we have made as a result of the level of thinking we have done thus far creates problems we cannot solve at the same level of thinking at which we created them.

Insanity is doing the same thing and expecting a different result.

Albert Einstein

It’s time to stop making excuses. No time to test? No time to think about why the last project turned out so shitty? No time to try and do it right this time, but we always make time to re-code the old system again and again. We all need to ensure that we are finding the right balance between urgent and important and not confusing the two.

Change is hard. It is; but let’s stop making excuses about how hard it is. We know it can be better, let’s say “no more hacks” and start changing. It’s possible that toe-dipping won’t work; there is no such thing as half a paradigm shift. I prefer measure, experiment, tweak. Rinse and repeat.

But don’t forget to rinse. This is a people business and you can’t change a person with a reboot and a clean build. Maybe you can’t change a person at all, maybe they can only change themselves. If they aren’t willing.. well the door is right over there; make sure it doesn’t catch you in the ass on your way out.

Can you make your development team another ThoughtWorks? Another ObjectMentor? Another Google?

Home-made food = GOOD. Home-made framework = BAD.

Title says it all; but it came out of a bit of prototyping that I was doing using LINQ to SQL. After a few attempts to make it testable, it was clear that we were making out own dependency injection container!

Home-made framework=BAD!

(credit for the phrase goes to Johan)

Fowler’s Law

Fowler’s law is invoked when you have a penetrating insight into object-oriented programming.

If the quality of your insight is very high, you realise that Martin Fowler published the idea only five years ago. If the idea is poor, you realise that he published your idea more than 10 years ago… to demonstrate how many people still don’t get it.

Rocketeer knows good agile

So, I was reading this book, Great Mambo chicken and the transhuman condition *, which has a short quote from rocket engineer Bob Truax and what he thinks about developing rockets.

“We came up with a set of ground rules for designing a lanch vehicle. Make it big, make it simple, make it reusable. Don’t push the state of the art, and don’t make it any more reliable than it needs to be. And never mix people and cargo, because the reliability requirements are worlds aparts.”

Oh yes. He knows. Understanding that quality is an adjustable feature and don’t waterproof something that will never see water.

* the book is slightly odd; it is a bit of a rag bag of bits and pieces about nanotechnology, rocketry, going into space, and transcending the physical flesh and moving our minds into giant fractal robots. All rubbish but fun stuff.

Patterns of Enterprise Deployment – Single Shared Application source

This is part of the Patterns of Enterprise Deployment series.

Summary
The application is run from a shared location; for instance a web site or a network-accessible file store (like a shared folder). End-users must go to this location using a hyperlink/shortcut to access the application.

Difficulty
Low

Advantages

• Simple to set up, easy to understand for developer and business users
• Version control for an uncontrolled number of end-users is simple
• Updates to the application are immediate for new instances of the application
• The app can be run from anywhere, there is no need to install anything on the users machine (probably – there may still be browser issues or sometimes applications will require runtime environments like .NET framework or Java)

Disadvantages

• Sometimes not scalable in the case of a shared file, or a simple web site
• maybe performance issues for users who are accessing over the internet from another country
• updating the application, while people are running it may be difficult. Some web server applications help out in the this case by controlling when the binaries are reloaded. In any case, running instances of the application will not get the update and need to restart.
• In a shared file source, you may be unable to replace the binaries whilst an user is running the application as the file may be lock by the OS.
• If the network is down, the application is also unavailable; this may be the case anyway, if the application ha multiple tiers. However, if the application source is on one network location and the components required to run the application are somewhere else this may be irritating to users.
• Location variation in “standard” components — e.g., variation in behaviour of web browsers or Java versions — may cause problems

Use when

• the application is an end-user application
• suitable for corporate environments where you can be sure of some standard components to support your app(e.g., .NET, Microsoft Office etc)
• you need to deploy to a changing group of users

Don’t use

• The application source is on a network that may become inaccessible
• If users leave the application running all the time, they won’t get new versions without restarting.

My experiences
Website applications should be the ultimate way to avoid deployment issues. A way of getting you application accessible to your users any time, any place, anywhere. The corporate net is down? Fine go to a web hot spot with your iPhone and you are back! Often, it isn’t that simple. When you require multi-browser support in a complex application you don’t get that for free. It can be a huge sink of time to work the bugs out of that. To a lesser extent you can see the same thing repeated in more homogeneous environments. For example applications that use Microsoft Office as a platform; your users may claim that they are all on the same version but relying on it is a sure way to find out that some of them aren’t.

However, this is a simple one that works well for vanilla GUI apps that need to be accessible most of the time. Especially if they are used everyday by someone, but each person only uses the app infrequently. As long as they can find the right shortcut they will get the right application without any problems.

Patterns of Enterprise Deployment: Two-way data pump

Summary
When you have a new format or location for data, you need to support them both for a period. The data formats may be similar but housed in different technologies, or the technology could be the same but the format/schema of the data could be different. The data formats may be identical but you wish to have two servers that update each other. Sometimes this period where both sources will be months or even years, sometimes just a matter of minutes while you update all the servers in your enterprise with the new version, but don’t want any downtime.

The pumping mechanism can be one that you implement yourself or can be based on other technologies. In the simplest case, you have two tables that both contain the data in question; you put triggers on both tables to update the other side. In a more complex case, you have a file repository of data that needs to be kept in sync with a database.

In either case, you can adopt an event-driven or polling based strategy.

Use when

• you don’t want to, or can’t, remove all uses of a datasource in a BigBang deployment
• you are unsure of the new system and want to run in parallel for a while

Don’t use when

• the changes in data are radical or conceptual; for instance, if you have a one-to-one relationship between entities in the old model, and in the new model you also permit one-to-many relationships you won’t be able to pump that data both ways
• it is very important to get the latest data and you can’t transactionally update both stores.
• you have more than two sources of data; trying to do a multi-master merge is very hard and would require many constraints like a low number of updates and a globally unique way of identifying changes (i.e., GUIDs or a unique ID service). This would almost certianly also require changes to both systems which is what you are trying to avoid.
• you won’t be able to kill the old system; if you can’t then you will have three things to maintain: the old, the new and the pump that shackles the new system to the old and holds it back!

My experiences
Most of my experiences are when both of these sources are databases and I’m refactoring the database to a new schema. Sometimes it isn’t performant enough to use a view if the changes to the schema are deep. For instance, if the new schema requires a cursor, a CROSS APPLY call or any other subquery that executes once per row, then performance may be an issue, especially if people perceive that “the old system was faster”.

I’ve also used this when making a transition from a 2-tier to a 3-tier stack. Some callers are going right into the database and some are looking at the application tier that uses another schema but they both have to stay in sync. This was a bad one that was done with a combination of handwritten sprocs and triggers that had a lot of special cases to cope with the weirdnesses of the old system.

This is one that isn’t nice, but is often a must have.

If the data formats are very different but both in databases, you may find that datawarehouse strategies serve well and both can be reading and writing to a common repository.