I have mixed emotions about all of this. Some may say that it’s like putting lipstick on a pig, but in fact I don’t think Windows 7 is a pig at all. It beats any other desktop OS, bar none, and no, I don’t want to hear it from the Mac crowd (see my previous post). For me, it feels like putting an enhanced Windows Phone 7 wrapper on the desktop OS. This is great news for the upcoming Windows 8 tablet user and market. For me, for now, it feels like my phone UI is getting in the way of my desktop UI. I’ll probably get used to it later, but for now it just feels strange.
In any case, the press release and the little demo video seems to answer three primary and critical questions. Here are my first impressions and a few key frames from the video to tease you into watching it.
What is a Windows 8 App?
The touch enabled Start Desktop
What is Windows 8?
Aside from assumed improvements in the kernel, driver infrastructure, etc., we learn from this demo that the primary target UI is the touch interface with cool split thumb-friendly touch keypads for all platforms. Of course support for the 20th century input devices formerly known as the keyboard and mouse continues to be available. Behind the new touch enabled "Start screen" with smart app tiles, the old "Start button and menu" and desktop interface can be found underneath the covers. So you can have your touch-cake and eat your mouse and keyboard driven app-cake too. Smart.
Dragging the next desktop pane into view. Note the distinctly non-Windows 8 Word icon.
What Should a Developer Know About Windows 8?
Tweet in your Windows 8 App while balancing the budget in your mundane Excel spreadsheet.
HaHa! HaHa! HaHa! HaHa! HaHa! Ha!
To the Mac community, all I can say is, will you now please SHUT UP about your “secure” OS.
Welcome to the real world of being a target and having to take measures to protect yourself. Now that you have realized your security was never security but obscurity, perhaps we can all have an adult conversation about battling the bad guys together instead of us having to listen to you crow about your false sense of superiority.
When you can't drive and you can't see over the back seat, you must trust the driver. The measure of that trust is determined by what you do when you are late. This is the conundrum of does and doesn't.
Effective management is simply pushing the right buttons and pulling the right levers at the right time. This requires sufficient information, analytic thought, rational decision, and consequential action. Asking questions and thoughtful contemplation are not enough. If you cannot make decisions and act upon them, you are a researcher; you are not a manager.
- Sufficient Information
- Analytic Thought
- Rational Decision
- Consequential Action
Every healthy human being manages something. You wake up hungry (information) and you think about bacon (thought) and you decide to limit yourself to two pieces (rational decision) and you throw three pieces in the pan (consequential action) just in case one of them burns even though you know you’ll eat it anyway. Okay, we’re not all perfect managers. Actually, I’ve never met one, so I’m not sure there is such a thing. Excuse me while I take a break to finish that third piece of bacon…
What the world needs is yet another blog post on how to manage software development, so why not write it myself I ask. Unable to find a good reason to stop here, I’ll give it a shot. If you continue to read, you and you alone will be responsible for anything you might learn.
There are books, graduate courses, and no end to rambling blogs, so I’ll shoot for brevity and clarity here in Part 1.
- Know Your Team
Computers do not yet write software all that well by themselves, so you’re stuck managing the people. Your process or you dictate what they will work on and, by virtue of time constraints imposed, how they will work on it; this is the essence of management.
- Be Decisive and Take Action
Collaboration is a meaningless waste of time unless it is followed by real decision and actions that lead to positive results. If you cannot make decisions and act upon them, you are a researcher; you are not a manager.
- Be Honest and Fair
If you say one thing to your team on one day and deny having said it the next day, your team will lose confidence in you and rebuilding that trust may not be possible, so choose your words and promises carefully. And if you make a mistake, admit it readily and apologize where appropriate. Your team will see this as a mark of a true leader.
- Demand Accountability
When you assert a process rule, enforce it. Hold team members accountable. Start with gentle reminders and further training but do not allow repeat offenders to skate without consequence. If you do, your process is not a process and it will fail.
- Eliminate Needless Meetings
Developers generally hate meetings with good reason. Most meetings lack an agenda, lead to no discernable action items, and there is rarely a copy of the minutes minutes and action items distributed to attendees. Most software development requires long, uninterrupted periods of time to effectively solve problems and complete complex tasks. Useless meetings in the middle of the day can ruin a developer’s entire day, throwing his productivity into a spiral, so group meetings into a single day where possible to eliminate or reduce the disruptive effects.
- Review Everyone’s Work
You may not understand the code, but having a developer walk you through the code, discussing the decisions made and showing off just a little will go a long way toward educating you and inspiring your developer. Review and discuss documentation, designs and test plans with interest. Spend the time to learn from and guide your team.
- Get Yourself Out of the Meetings Cyclone
Decline a leadership training or management committee meeting from time to time in order to do some real managing. Remember, the word “manage” has its root in manus (hand). If you don’t put your hands on it, you can’t possibly manage it.
- Create and Shepherd Processes
Everyone knows how to manage and can do so if you give them a process that establishes guidelines for what information should be considered, what decision making process should result, and how those decisions will become actions within the constructs of the process you have created.
Well, that’s enough for part one. More on the same topic later.
This morning I read a post by Seth Godin, a favorite of mine, which presented and discussed an essay written by Paul Graham of Y-Combinator called Maker’s Schedule, Manager’s Schedule.
I regret that this cogent essay and essayist have escaped my notice until now. It reveals what every programmer knows and has experienced with regard to meetings, and I’ve never found a better treatment of the subject.
It confirms with clarity that programming is a creative art, an act of creation or making. Such work cannot be effective and productive with multiple disruptive meetings every day. And sometimes it only takes one meeting, even a short one, to blow your whole day.
The content and contention in a single meeting can serve to distract a programmer to the point of rendering him effectively useless for the remainder of the day. This is true not only for the programmer but for anyone whose primary function is to make things of complexity.
Consider preventing the daily standup from becoming a meeting in which the resolution of identified impediments is attempted. And never allow the standup to devolve into an ad hoc project status review and planning meeting with the question, “When will you have X feature done?” being asked.
Consider piling all such meetings to which makers must be in attendance into one single day of the week, perhaps Friday or Monday to ensure the largest contiguous uninterrupted period for making, preferably in the late afternoon, so that we get every ounce of making from our makers that the company’s hard won cash can buy.
It’s more than something to think about. It’s something a manager could manage if the manager simply chose to do so, and it’s something a maker would appreciate more than can be expressed in written word.
I’ve long been taught and believed that the truth will set you free. But fear is a powerful counter to belief, especially when that fear is rooted in the compellingly powerful human instinct to survive, to preserve your livelihood.
I was reading Ken Schwaber’s The Enterprise and Scrum today and came across the following passage which I deeply appreciated. Ken is writing about to the development team’s fear of telling the Product Owner that they cannot deliver on their commitments for a Sprint.
When I discuss this kind of fear at the courses I teach, the attendees’ own fear is palpable. The soon-to-be Scrum users don’t think that the transparency, or truth, is acceptable where they work. They tell me that they will be fired if they tell the truth. Truth isn’t what their customers want to hear. They tell me their customers will find someone else who will lie to the them if they don’t. I have seen this in class after class for five years. People in product development think that their customers want to hear news only if it is good news and would rather hear a lie than the truth. “Lying” is a harsh word. But what else do you call saying that something is true when you know it not to be true? What else do you call misleading someone with information or holding back information that would have led them to better decisions? The Product Owners want to believe in magic, and the developers support their belief by lying. “Can you do this project by this date?” “Sure, no problem.”
The developers are aware of the complexities that cause changes to their original estimates. They are aware that the customer is unhappy. If a project manager is approached by a customer 60 percent of the way through a project and asked how the project is going, the project manager doesn’t really know. She knows that some things are going well. She also knows that some things are not going so well. She also knows that she hasn’t checked up on some things that could prove critical. However, saying “I don’t’ know” is unacceptable, so project managers have learned to say, “Right on,” “Right on target,” “Piece of cake,” or anything equivalent that will get the customer to go away and leave them to try to get everything on time, on cost. Basically, they lie. It is simpler than exposing all the nuances and complexities that add up to “I don’t know.”
Project managers might also believe that lying saves time. But because Scrum relies on transparency, misrepresentation undercuts the entire application of Scrum. If the Product Owners do not know exactly where things stand at any point in time, they will be unable to make the best decisions possible about how to achieve their goals. They need the best information possible, whether they view it as good or bad.
I don’t know anyone in this business who cannot relate to Ken’s assessment. I am coming to the conclusion with every additional year I spend in the role of code monkey that anyone, with proper preparation and context, can handle the truth, even non-technical folk. I am learning to reject the often held notion that these people are just not able to appreciate the nature of complexity.
Yes, Product Owners not only must have the truth but in fact they can handle the truth even when the truth is not welcome news. I have seen Product Owners ignore the truth but I have never been fired because I told the truth. What Product Owners have a very difficult time handling is the sudden discovery of the truth after having been lied to for long periods of time.
Whether we choose to tell the truth from the start or to lie to ourselves and our Product Owners, eventually, as the Bard would be wont say, the truth will out.
So I still believe that the truth will set you free. Fear will leave you miserable and in chains with the secret knowledge that the truth will be discovered sooner or later by those from whom you’ve hidden it. Freedom is so much easier than we sometimes think.
Nothing in this post is original. It’s just my reduction of the principles of class design from Uncle Bob in his Principles of OOD. If you don’t want to read, listen to the Hanselminutes interview with Bob. I just want to record my thoughts on these items here for posterity.
SOLID is just another acronym but if you are writing code it’s one you ought to know about.
SRP – Single Responsibility Principle: “A class should have one, and only one, reason to change.”
OCP – Open Closed Principle: “You should be able to extend a class’s behavior without modifying it.”
LSP – Liskov Substitution Principle: “Derived classes must be substitutable for their base classes.”
ISP – Interface Segregation Principle: “Make fine grained interfaces that are client specific.”
DIP – Dependency Inversion Principle: “Depend on abstractions, not on concretions.”
These are not new ideas and I’ve not visited these lately nor can I claim to practice these principles in everything I do. In fact, I’m sure that I don’t, but I am convinced that the more I follow these principles, the better my code will be.
I’m going to spend the next few days reabsorbing these and reading the PDF docs on the www.objectmentor.com site. If you want to follow along with me, start at the top of this post and follow the links.