<Rant> The “Cloud” in Cloud Computing is a Stupid Name

Come up with something new, people! It's like saying "fog". People are foggy and cloudy on the cloud. They don't know what it is. I don't know what it is (in total) and I think I should. That's a problem if you're trying to sell someone something more than snake oil. Let's start offering real value and get clear on what the cloud—or our service in the cloud—is!!!

Refactor Later If Necessary

Don't be a perfectionist about the software you're designing. There's always another time you can come back and fix what you built. That's the beauty in fact about object-oriented or component-oriented programming is that the components are "swappable". If I messed something up this time around, I can always go back and fix it later. Insist, however, that the STRUCTURE you create is very good and that you have a solid, defensible, base architecture to stand on. Be fine with rafactoring later if you have to; you'll probably have to.

Be Cool Under Pressure

Sometimes you have to deliver rapidly and set expectations with people. You could burn yourself out and work 80 hour weeks or you could take it easy. Be cool, confident, calm and don't burn yourself out. Make reasonable commitments with people if at all possible.

Get Refocused

I feel distracted at the moment. My main project at work is out of mothballs and I'm trying to get things done on it. The learning curve on Silverlight, RIA Services, and passing data from SQL Server isn't easy. I must plod forward.

The Librarian Role is Needed

In companies there needs to be a librarian or secretary. Teams are busy and produce a lot of things. Even with good IT systems, things don't get checked in and project results or artifacts stay on local machines. This is a knowledge management problem when the resource moves onto something else and frequently causes rework. I propose the role of LIBRARIAN. This person would make sure that everything is done. This is a hat the project manager or functional manager could manage.

Lots to Learn in Programming User Interfaces

It takes a long time to get good at programming. I still don't feel like my "toolbox" is working very well from the front-end to the back-end. I am stronger on the database side and now I have to bridge the gap up to the UI. The UI technologies are crazy in my opinion. Silverlight and .NET RIA Services are compelling. I like how they're working with data binding. .NET 2010 seems to have some cool data binding "drag and drop" functionality (see http://channel9.msdn.com/posts/kmcgrath/Silverlight-Object-Binding-in-Visual-Studio-2010-Beta-2/). ASP.NET MVC is different. I'm more familiar with HTML as my UI and JQuery is a very nice extension for that… Windows Workflow Foundation (WF) is another that I'd like to use here to figure out how to handle the different activities in the workflow I'm currently designing. Another cool / promising technology is .NET Entity Framework. Looks cool and now there's going to be SQL Server Modeling Services and a language called "M". So much to learn!!

Defer in Order to Manage Multiple Customers and Interruptions

I've had the luxury for about three months now of working on projects that have been generally serial in nature. That's changing a bit as I've finished a few things and they're in peoples' hands.

I'm going to implement a new personal policy that is to start and finish the highest priority thing as soon as I can "reasonably wrap up and mothball" what I'm currently doing. I'm currently working on an app that is due in a few weeks. I'm going to finish any loose ends, write down my next steps and move onto the other more pressing thing now. I'll dredge up the other project when I'm done with the current one.

Ideal Software Development Manager

Listens well, writes code, willing to help, willing to be interrupted, not too busy or randomized by other things, values you, smart.

Plan for a Longer Review When the Next Task is Big or Important

I have a problem that I'd like to share with a coworker to get his input. He's really the customer on this so I don't want to waste his time. I have to get ready to ask the question and engage him. This particular question I want to be reasonably BIG because I want to spend some time with him designing the next mini-sprint or story I'm working on; really the finish of this iteration of the product: the first prototype! I've basically finished my current story "build middle tier" and now I have to work on the next story "enable front end". The new story is pretty complex for me and I don't know much. He doesn't either. I could start in on it and ask him things as I go, bit by bit, but I may ask now, show him what I have so far and step into the next big problem, chartered and re-energized by him.

I'm an idealist and want to have shared mental models and designs between people. I don't want to work alone but sometimes I do and have to. This is the case now where I want to take the risk of engaging the customer so we can co-visualize and plan the last leg of his/her project. I don't want to annoy this person but I want to keep them engaged and involved.

Back-to-Front vs. Front-to-Back Systems Design

We all think in models and our computers allow us to build models, so of course use them, right? It would be ideal to have a model of our system that we instantiate. We draw something or configure something and a system comes into existence. That's the basic practice of development but it's much different and far more iterative going from front to back and back to front. Writing code is a sometimes aggravating process as you validate your coding concepts against your mental model of the ideal (or good enough) solution. The Model-View-Controller pattern is very popular these days with Ruby on Rails and ASP.NET MVC. These solutions allow developers to pass data between the layers and control how things are presented. There's a flow they have in mind and that's a really handy tool! I'm building a Silverlight UI right now and I'm preparing the underlying data model for on-screen display. SOMEHOW I have to sync up the back end with the controls and intended user scenarios in the front end. That's tricky. I've been working from back to front but now I'm having to go from front to back. Somehow these worlds will collide!

Computers will be better when:

When software engineers figure out how to allow a user to drag objects around and relate them to other objects in many flexible ways (not just hierarchies), computers will be way more powerful.

Enjoying the Tranquility of Authorized Research

I was obsessing yesterday over the idea that I didn't know how to do "data binding" in .NET. I wanted get help from my coworker because I thought he knew about it but it turns out he doesn't. I talked to him this morning and he told me to do the reading and research necessary to "get 'er done". Cool! So now I get to become my team's resident expert on data binding in Silverlight on .NET. I'm looking forward to experiencing the tranquility of learning something new and want to learn, at my pace, on a cool project, at least for the moment. Thanks, V!

Refactor Later

Start and finish your design. You may not know exactly how to do it but you need to finish. Surely you can engineer a way to make it work but don't get bogged down in asking too many people for input. Maybe don't ask anyone for input at all. You can get the input later when you finish and at that time, either enhance this creation or the next one.

Some preferences don’t matter; they are for you

Sometimes you may think you want people to offer input on something you're designing but you typically don't need this. Keep steaming ahead and make decisions about the design as you see fit. Be creative.

It’s better to ask for forgiveness than permission

Authorize yourself to do something really good today. Maybe the others won't like it, but finish it and make it tight. Show it to them and gauge their reaction. Without a doubt it will be a learning experience.

Don’t be parochial, get the job done!

I've blogged before about how you have to wear different "hats" to do well in IT. I think the hats are: project manager, program manager, product owner, customer, developer, and tester. That said, as a consultant (or employee for that matter!) the "that's not my role" mentality is completely retarded. Don't do it. Wear many hats and don't develop a not invented here mentality! Make sure you develop skills in all of these disciplines and figure out how you can get the job done if you're given any of these tasks. Learn from the masters of these roles and be the "project manager" to drive toward getting the job done. Don't be parochial!

Training Product Owners Is Challenging

Customers can be difficult of course. I say this because many people might not know what they want or how to get there and your job as a software development consultant or team leader is to communicate with this person as effectively as you can and give them products that they can use in THEIR processes. Some core skills and lessons that you need to teach the product owner (whoever he or she may be are): 1) software development is difficult 2) there is uncertainty in how the solution will be exactly created and knowing what exactly will come out is a minute-by-minute problem for a software developer or leader 3) estimating when you'll be done is difficult 4) there exists a process of continuous improvement and improvement of the customer relationship. That process referenced in #4 is YOU!!!

Waterfall doesn't work a lot of but it's fine to have frameworks and principles that you follow. CMMi, Six Sigma, Agile, PMBOK, MVC, etc. They all matter. In the end, something has to get done and agile is a way of breaking up the problem FROM THE BEGINNING about what needs to be done next. What's the risk? What's the priority? Can we do it? When do you need it? Removing as many of these impediments as is possible as fast as you can is the way!

I Learned a Lot About Software Development and Communications from Scott B.

A former coworker, Scott Brown, knew Agile. He'd lived it on the CodePlex program at Microsoft. I wasn't a current practicing developer at the time I was ScrumMaster of that group but I am now. I probably learned the most from Scott. He was very pro-Agile; a zealout, I'd say, but retrospectively he knew a lot about the process and effective communications. He was all about velocity and getting things done; pragmatism. Our team wasn't probably ready at the time for that level of engagement (I know I wasn't) but I am now.

Thanks to Scott for showing me how software development can be fun and we can reduce randomization through quality communications.

Get to a working demo as fast as you can!

You can potentially be perfectionistic and want what's perfect for your app but in the end you have to release it to users and let them break it. Think through the risks and issues of the scenarios they're going to do and plan for that. What are the scenarios? How will you know that they're working well? Answering those questions should be the input to your sprint and its "definition of done".

Cautiously Demo Your Work to Build Relationships with Customers

Caution is the key word here. You don't want to bore people. Let me explain:

The purpose of the demo (or asking for help, input, etc. from your customer or manager, teammate, etc.) is to impress upon them, and to build your relationship with them as much as you can. The more they like you, the better off you are; the more they'll like your products most likely. The more you waste their time with triviality or demos that suck, questions that are obvious or that you could have answered on your own, the more you'll turn them off, bore them, and generally make them dislike you. Sure, they may care about you as a person but what they really care about AT WORK is the product and its QUALITY. If you demo boring stuff or unfinished things or things that simply confuse them, they'll disengage and possibly dislike you, probably ignore you. They'll avoid your products as well. You don't want that.

In total, THINK HARD before you ask someone for help or look at your work. Be in control of what's being presented and don't welcome scrutiny or doubt in your approach. If the demos are good and you get the kind of feedback you really needed in the first place then you'll be in the good! Avoid "ringing the bell" at any given moment; bang the gong when you're ready to summon them!