Engineering

,

Truly a Project from Hell

,

Reddit resurfaced a 10-year old story about a project gone so terribly wrong that it sounds truly horrific. Just one anecdote from the article:

One developer was given the task of checking why right-clicking on the interface completely froze the application. After several days of careful examination and incredible amounts of patience, he found out that right-clicking worked fine, only that it took about 45 minutes for the context menu to popup. Menus were all dynamically generated from huge (static!) content every time you right-clicked the main window.

It's almost impossible to believe that such things exist.

There also a follow-up post with answers to common questions.

 

,

Route 53 in AWS Management Console (and their hidden reminder)

,

Yesterday Amazon announced immediate availability of Route 53 (their DNS service) tools in AWS Management Console, which is great news for all the AWS users. But it also bad news to services like Interstate53, which I was using to manage DNS records hosted on Amazon, because it immediately renders them irrelevant. It is good time to remind ourselves how addon development is not exactly the best spot for software vendors and how in some cases you can still compete against the platform vendor by having significant value add.

Your app vs. GMail

When you work in what I call a "controlled environment" it is kind of easy to be dragged into compromises in different areas of quality of your products. As with many other things it does not necessarily happen because you want to compromise, but simply because you can do that. There are many implicit myths about controlled environments. Here are just a few:

  • In controlled environments users have to use your software and therefore you can compromise on usability and user experience. After all users to not have alternatives to in-house corporate software tools.
  • In controlled environments users have to use your software and therefore you can compromise on performance tuning. After all users to not have alternatives to your software.
  • In controlled environments it is ok to provide something "good enough" software simply because all the other corporate software users have got on their computers is crap.

None of that is actually true nowadays. Every corporate user also uses GMail for his personal e-mail. Every corporate user also uses Mint.com to manage his personal finances. Every corporate user also uses Flickr to organize his photos.

We all know that expectations are set by previous experiences, especially, when it comes to non-functional requirements and qualities, which are hard to quantify, like usability. Users have already seen what is possible in other apps and they want to be able to get to the information managed by your apps in a matter of a few keystrokes, like in GMail. They want your apps to produce relevant and nicely looking reports, like on Mint.com. They want easy access to functions they need while focusing on the main thing they do, like with Flickr.

When developing corporate app you compete with Google, Intuit, Yahoo. In modern world you do not have benefit of controlled environment and you have to compete for users' attention and buy in. These days the best recognition for corporate software engineer would be when user while working with custom corporate software system says "Wow! I wish GMail had this too..."

Webinar: The Business Driven Software Development

Net Objectives conducts a series of webinars on Business Driven Software Development:

This series provides an introduction on how to achieve Business Agility. Business Agility enables an organization to respond quickly to external forces (such as new market opportunities and competitive forces) as well as to respond quickly to new insights attained internally. While many organizations have achieved the local optimizations of more effective teams, few have achieved agility at the organizational level. Even when team agility has been achieved, if improvements to how the business is selecting their product enhancements isn’t done, overall return on investment of software development may not have significantly improved.

First event is tomorrow at 9 AM PST. Register at the event page to attend the webinar.

One simple step to better configuration management

Many say that configuration management is hard. It is. 100% correct, "as the books says" software configuration management is hard. It takes tools, skills, discipline and effort to build and support reliable and effective software configuration management process. It is especially difficult, when there is already some process in place and improvement involves change.

My experience shows that it is particularly challenging when it comes to non-source code items like documentation and release packages. Can you imagine following dialogs with project team members? I can…

Managing source code:

--Is it necessary to follow Configuration Management practices, when you work with the source code? --Yes!

--Do you use source code control system during development? --Sure!

--Would you start coding without SCC in place? --Absolutely not!

Managing release packages:

--Should you manage configurations for you release packages? --Oh, yes!

--The best way to do that is to be able to recreate any version of release package... --Oh, yeah! That's the best way, especially, if you hook this up to automated builds and tests...

--Do you do that? --Well... You know, that requires time to setup. We are so busy with other tasks actually writing software, so we never actually got to that... And, by the way, our existing process is not that bad...

--But still you can get all the previous release packages, right? --Well, I guess so... We have a share where all the releases are uploaded.

--Do you delete files from there? --I think so. When we need to.

Managing documentation:

--Should you keep track of the versions of all the development-related documents that you've got? --Yes, definitely!

--So you do that, right? --Well... Not exactly... You know SharePoint (or another tool, you name it) is somewhat difficult to use (or setup). We just put the file in a shared folder or sync over the e-mail. When the document is final, we put it into SharePoint.

--I see... But you do change version number on the document each time you edit and keep it somewhere, don't you? --No, not really. Do we need to?..

Generally, the further you get from the source code the worse it gets.

There is a simple, not ideal, but simple remedy to this, which lies in mimicking what source code control system does:

Never overwrite or modify files! Always create new!

After all, we all have got 500Gb drives in our laptops - we have to put them to work.

,

Zooming in on a design

,

Have you ever worked with, maintained, explored a system which looked and felt really great in one area, but was really awkward and clumsy in another one? That was an instance of an elephant on the crutches. Elephant

This often happens, when design specification was not consistent in the level of detail for different parts of the system. And here is how this may happen.

When you design a system, it is never going to be plain and the same wherever you look at. If you have a database and a user interface - those two parts are already different enough. Such diversity naturally leads to the fact that there are some parts that you enjoy working on more than others (after all we never like doing everything that we do).

What happens next is that you spend much more time thinking about parts you like (because there you use new fancy technology, or neat engineering approach, or who knows why). Therefore you add more details to design of those subsystems that you really like. The outcome of all of this typically would be a specification that is an elephant with crutches instead of hind legs, because elephant's butt was never you favorite part of the system and design of this "subsystem" never was detailed enough to make sure it is consistent with the front.

Ideally, your design should be like Google Maps: you should be able to zoom in and zoom out on any part you need. It does not make sense to have a map, which shows each and every tree in your neighborhood, but gives you only a vague idea about how to get to grocery store 5 miles away.

When developing and documenting design you should gradually and consistently increase level of detail in your specification. Ideally, difference in granularity of descriptions of different parts between any two parts of the system should never be more than one level. One possible way of zooming in would be to describe

  • System + external interfaces, then
  • Services and components, then
  • Add their interfaces, then
  • Add interaction (Sequence diagrams) and edge classes, then
  • Components' structure and internal interactions, then
  • Class-level specification for key requirements (functional and non-functional)

This is not the only possible way to zoom. However, when you have class diagram with methods and their parameters, but do not have stored procedures defined for your database, you are doing something wrong (or, hopefully, your design specification is not complete yet).

Design specification is only useful when it can help you answer questions you get during development. This essentially means that you should be able to navigate it and find things - which is zooming in and out and seeing enough to make the right turn.

,

Weekend listening: a couple of interesting podcasts

,

Now when my commute went from 10-20 mins to 30-40 mins in each direction I quickly burned the backlog of podcasts. I gave a try to some new and so far I like what I hear. Here they are:

What are some of your favorite podcasts?