With our obsession for newness, those of us who work in the tech industry often fail to understand the historical roots of our technologies. Case in point: telegraph operators more than 150 years ago were sending short messages called "graphs" that were surprisingly similar in form and content to Twitter tweets.
One remarkable example was recently discovered in the Museum of Telegraphy in Harrisburg, Pennsylvania. It is the transcript of a telegraph operator's comments during Abraham Lincoln's famed Gettysburg Address in 1863. The transcript was shared with me by a friend on the museum staff, and I'm pleased to reproduce it here:
=====
Still waiting for the Pres. to commence his speech. #gettysburg
Good heavens, I should have foresworn that fifth corn dodger for lunch. #gas #dontask #gettysburg
Starting now. Pres. waves to crowd. #gettysburg
Four score and... WTF is a score? 25? #pleasespeakenglish #gettysburg
Okay, it's twenty. So "87 years ago the country was founded." Why not just say that? Duh. #gettysburg
Heh-heh-heh. He said "conceived." Heh-heh. #gettysburg
"Now we are in a great civil war." More duh. #gettysburg
@zebekiah1134 I know, it's my own fault for buying lunch from a wagon. #gas #gettysburg
Hoping to get in two miles this afternoon. Depends on how long this speech goes. #gettysburg
"It is altogether fitting and proper that we should dedicate this cemetery." Ooookay. #gettysburg
Saw @matthewbrady this morning, taking pictures of guys with big beards. #muttonchopsrule #gettysburg
"The world will little note, nor long remember, what we say here." #nokidding #gettysburg
Hey you in the hat. Yes, you. Take it off, you're blocking my view. #gettysburg
"This nation shall have a new birth of freedom." Great, finally we'll get some details. #gettysburg
"Government shall not perish from the earth." Good to know. #gettysburg
Where's he going? #gettysburg
What, that's IT? I waited five hours in the sun for THAT?? #ripoff #votedemocrat #gettysburg
Maybe I'll make it four miles. #outahere #gettysburg
=====
Posted April 1, 2012
2011: The microwave hairdryer, and four other colossal tech failures you've never heard of
2010: The Yahoo-New York Times merger
2009: The US government's tech industry bailout
2008: Survey: 27% of early iPhone adopters wear it attached to a body piercing
2007: Twitter + telepathy = Spitr, the ultimate social network
2006: Google buys Sprint
Software Development
GUIDELINES FOR SOFTWARE DEVELOPMENT
(Test)
(Test)
Here are some time tested guidelines that have been used extensively to deliver web development projects successfully, on-time and on-budget. Although most of the projects developed are between 1 to 10 man years of effort, these tips also scale nicely for smaller projects of 2 man months to larger projects of 25 man years.
1. Understand the user’s needs, write the specs before coding and keep them up to date. Develop the User Interface with the specs and flush out design issues.
2. Break projects into modules of 1 week or shorter.
3. Implement risky modules early.
4. Create validation milestones, every 3 to 4 weeks.
5. Provide the necessary resources.
6. Get developer buy-in for features, timelines and milestones.
7. Keep people accountable to their commitments.
8. Resist “feature creep” during implementation and testing.
9. Use automated functional testing tools and do stress testing.
10. Under-promise, over-deliver and plan a pleasant surprise at the end.
In every project, one or more of these guidelines will be broken. A breach of a guideline does not mean a project will be unsuccessful. Other guidelines will usually pull you through and help the project succeed. It is the large number of breaches and the depth of the breaches that will create project failures.
1. Understand needs, write the specs before coding and keep them up to date.
Once you understand the functionality to be built, you’ll need to do a detail level design, preferably in terms of use cases. Work out the design details before the start of coding. Doing so during coding will increase the failure rate of the project. This does not mean you can not make design changes later, just try to minimize those changes by doing a great job upfront, as changes are the most significant factor contributing to project failures. If a change costs $1 to incorporate during the design phase, the same change will cost $10 during the coding phase and over $100 after the system is in production. An easy way to minimize software development costs is to do a great job during the design phase and capture the details on paper so everyone on the project team has the same expectations. Develop the User Interface with the specs to flush out design issues. Once you lay out the elements of the user interface, your customers will see how this all comes together.
If there are any issues with the design, it will come to light. The user interface design is also a great process to flush out or capture the details that may have fallen by the wayside. Many projects utilize commercial components or code libraries that are new to the development team. I recommend developing a small test application demonstrating the team’s ability to utilize the needed features in the commercial components. Other than the coding involved for such a test project, no other development should take place until the specs are completed. Although we like most of the Agile development concepts, the upfront documentation of the design specifications is one that we differ in opinion, especially for remote teams. As you gain more insight and discover additional information that needs to be remembered, update the specs. When you make design decisions or changes, update the specs. Our ultimate goal is to make the specs a project bible where we can find most of the answers. Also keep in mind that our real output is the software, not the technical documentation. The specs are there to make the process work smoother.
2. Break projects into modules of 1 week or shorter.
When you have an architecture in place, break the tasks into modules of 1 week or shorter to get good visibility and predictability. For modules that are hard to break down, you can extend the timeframe up to 3 weeks. Most of the web modules we develop are usually 3 to 5 days in duration. Modules that take longer to implement are harder to manage and feature creep usually comes in, effecting deliverables.
3. Implement risky modules early.
Build modules that have some risk element, up front. If the project is going to fail, it may as well fail at the beginning, before you invest a lot of time, energy and resources. Try to understand what you don’t know as early as possible. The further away the milestones, the more unknowns there are. If you minimize the risks and the unknowns up front, when new things come up, you’ll be able to incorporate them into the project more easily simply because you left the easy stuff to the end.
4. Create validation milestones every 3 to 4 weeks.
Milestones are where “the rubber meets the road.” You want to be able to demonstrate the milestones for each piece of functionality, show that they are working, share them with your customers and get their feedback. If you missed the boat, you want to find out early. Milestones tell your customers that you are doing the right things, at the right time and the project is likely to be a success. It reinforces where you are on the project plan. Milestones also force programmers to focus on the deliverables and get to the minor details that are often left until the end and often forgotten. A milestone demo will usually flush out any issues, known, hidden or unknown. What we don’t know that we don’t know will usually come to hurt us. Use milestones to get everyone involved on the same page and prove your progress. Milestones scheduled 3-4 weeks apart are usually a good way to show progress and catch issues before they become bigger problems.
5. Provide the necessary resources.
NEVER start a project without knowing that you are going to be able to finish it. The people assigned to the project will not take ownership of their tasks if they don’t have the resources to finish them successfully and they will blame the management for that.
6. Get developer buy-in for features, timelines and milestones.
This is an important but often overlooked issue. Knowing the details of what you are building is one the most important factors in estimating accurately. After the design specifications are done, whenever possible, have the developers establish the coding timelines, rather than dictate the timelines to the developers. The developer is the one who understands how complicated the project is and how long it will take to complete. After all, they are the ones writing the code. If too much time is being requested by the developer, you can always ask questions, like “Why do you think this will take so long? Where do you see the problem with this project?”. Understand the issues, flush out the details (which usually solves the problem) and treat issues fairly to both side’s satisfaction in a friendly, fun conversations. You want to be able to hold developers accountable for the work that they are doing. In order to do that, you need to have everyone agree to his or her commitments wholeheartedly and establish clear expectations. Get their buy-in for the milestones and the timelines before they start coding.
7. Keep people accountable to their commitments.
This important point requires that you get the buy-in from the developers, testers and subject matter experts since you are going to keep them accountable. This doesn’t mean that commitments or timelines can never be violated, but it does mean that there needs to be a very good reason to break a commitment. If it is the developers’ agreed upon timeline that is violated, they can be held accountable. If the violated timeline was set by the management, the developers’ common excuse is that they tried, but the timeline was unreasonable or say “I didn’t make the commitment, you did”, whereby shifting the accountability. At the time the agreement is made, make sure that everyone is clear that they will be kept accountable to their commitments. Also be clear that everyone is expected to inform you when there is a good chance that they may not be able to keep their commitments. This allows you to manage by exception, giving you the ability to manage more projects and fewer surprises. Many times a problem caught early on can be mitigated so that it does not affect the deliverables.
8. Resist feature creep during implementation and testing.
CAUTION, HARMFUL IF SWALLOWED! This is by far the worst enemy of the projects, especially in new applications where Version 1.0 is being built. The customers will think of additional features or different ways of doing things during the project implementation or the testing phase, well after the design is completed and approved. We would recommend starting a new list for these requests, to be implemented as an add-on phase to the project, as soon as the project completes the testing phase. Resist adding new functionality unless it is trivial to implement (i.e. without effecting project timelines) or is detrimental to the success or the completion of the project. Be supportive but use your best judgment with the understanding that feature creep is a very slippery slope. Although hard to do, this is probably one of the most effective tips we can give you. The question to ask is “Do you want high quality software, with the desired features, on time and on budget, or do you want the flexibility of changing the feature set when you want, at a significantly increased cost and unpredictability?”. If you get a buy-in from the customer and the executive management team before the start of the project, this is doable.
9. Use automated functional testing tools and do stress testing.
Create a test plan while the code is being developed. It’s important to know what to test and how to test it, before starting the testing phase. This can be done on the surface, without going into much detail or it can be a very detailed test plan, depending on the amount of time and effort you want to spend on quality assurance. Unfortunately there is always a trade-off between high quality software with the minimal amount of bugs and the amount of money/resources/time invested in testing. You should find out where this trade-off is for your organization and do what is normally expected, unless it is broken. Use automated testing tools. These are tools that make repetitive testing fast, accurate and a lot easier. Once the test scripts are developed, the entire system can easily be retested whenever a new feature is added, just to make sure nothing has been broken unexpectedly.
Web applications will also need to go through stress testing, especially when the expected user base is over 1,000 users. Although the usage patterns and application bottlenecks differ from application to application, every new web application has at least one “Achilles Heel” that will bring the system to it’s knees. Test your system ahead of time and know what your limits are; every application has them. Today, servers are inexpensive and powerful; many performance issues can be solved just by adding extra servers. If you don’t know where your bottlenecks are, you will not know when to bring in additional resources. Know your limits, accept them or fix them.
10. Under promise, over deliver and plan a pleasant surprise at the end.
This adage is heard and known by almost all of us yet seldom put to practice. To your customers, always promise just a little less than what you can deliver. Internally, always push to deliver a little bit more than what you can deliver. I recommend keeping two separate project plans, one for development and one for your customer. Although this may seem a bit inefficient, and you may get eyebrows raised for not running the software development at maximum effectiveness, remember that software development is still an art, surprises will almost always happen and what will remember is how you finished the project. Successfully or unsuccessfully!
Murphy’s Law will present itself, something unexpected will happen, so at worst you want to be able to deliver what’s promised and maybe something slightly better. At best, you’ll either deliver additional desired features or deliver the project in less time, under budget, and really score big brownie points. That works for both the business
side and the technical side of the house simply because IT is now seen as a “trusted partner” in delivering the needed solutions on time, on budget. The business side of the
house is usually very happy because they get predictable results. Your developers are happy, because they are now seen as the heroes. Proper expectation management is vital to the success of the project. Good project managers will spend a lot of time in managing expectations by under promising, over delivering and especially planning a pleasant surprise at the end. This makes the projects look more successful.
The Real Significance of the New iPad
The reactions to the New iPad announcement this week were all over the map.
Some places said it was basically a yawner (link), while others bought into the "end of the PC" rhetoric (link) . Some people even warned all developers to stop programming for the keyboard and mouse, even for complex applications like computer-assisted design (link).
My take: I think the announcement was both more and less important than people are saying. Here's why:
This is not the end of the PC era
I'm sure I'll get some push-back from people who disagree, but I think the whole "PC era" meme from Apple is self-serving hype. Of course they want to convince you that the world is shifting away from a market where Apple has less than 10% worldwide share to a market where Apple has well over 50% share. I'd say the same thing if I still worked at Apple. And the iPad is shiny and sexy, while Windows PCs are old and boring, so I want to believe that the PC is dead. It makes me feel all Jetson-y. But think about it rationally for a minute.
First of all, what exactly was the PC era that is now supposedly ending? Was it the years when Windows was the dominant API for software innovation? That ended in the late 1990s with the rise of web apps. Was it the era when PCs outsold smartphones? That ended last year.
To many people, the end of the PC era seems to mean that tablets are starting to replace PCs as thoroughly as PCs replaced minicomputers. Or that the keyboard and mouse are going away. I don't buy it. We've been declaring the PC dead for at least 15 years, but we're still using them today because for certain tasks, PCs are the best way to get work done. It may be unsexy and it may seem old-fashioned, but if you're working on a big spreadsheet a mouse and numeric keypad are incredibly productive. And if you're writing a report, a keyboard is still the easiest way to input text (for now) and edit (for the foreseeable future).
Kind of like a steering wheel and pedals are still the best way to drive a car. I could do that with a multitouch tablet as well (three-finger swipe to the right means turn at the next corner, four fingers down means apply brakes), but sometimes direct control is the best approach.
And yes (comma) I have tried Dragon (pause) Naturally (pause) Speaking (pause) many times (period) (space) And I found that by the tame I went back and fixed all the types it created (comma) I had not saved any time (comma) plus it was difficult to speak in the sort of sentences I wanted to write because you know I kind of speak more casually than I write (period)
My point is not that touch and speech input and tablets are useless. I think they're great, and I've been playing with them for more than a decade. But I'm going to have the most productivity if I can choose the best tools for a particular job, and that means I still need a pointing device and keyboard for some sorts of work.
Now, if Apple were saying that the PC will be less dominant than it was in the past, I'd have no trouble with that. Although we're not seeing the overall death of the PC, we're definitely seeing a narrowing down of it. For tasks like reading or interacting with content, a tablet is far superior to a traditional PC, and if that's all you do with your PC, by all means get rid of it. But PC-like devices (or maybe mice and keyboards that connect to tablets) are going to linger for the sorts of work that they do best.
So if you have a touch-sensitive screen connected to a keyboard and mouse, do you call that hybrid device a PC or a tablet? I don't really care; it's a game of semantics at that point, and semantics are the playground of companies that want to score marketing points. Which brings us right back to Apple and its enormous tablet market share.
(Oh and by the way, the tablet needs a stylus for certain types of work. One of Steve Jobs' strengths was his willingness to revisit his assumptions when he was wrong, and this is one of those cases. I worry that since Jobs died, Apple may now get locked into his religious opposition to the stylus. That would leave Apple vulnerable to a competitor who does the stylus right by tuning the hardware and software to work together.)
What does matter about the new iPad
Two things stand out to me. The first is the screen. Yes it's very pretty, but that's not the point. The Retina display is a very nice feature in a smartphone, but in a tablet it's far more important because tablets get used more for reading long-form text like novels, textbooks, and magazines.
For displaying photos and videos, enormous screen resolution isn't actually all that important; what matters most is color depth. If you have millions of colors, the pixels blend together and most images look real even at 150 dots per inch. But for reading, where you have sharp contrasts between black text and white background, much higher resolution is needed. At 264 pixels per inch, the new iPad's screen is close to the 300 dpi resolution of the original LaserWriters, which most people found an acceptable substitute for printed text, and which drove a revolutionary change in publishing. I doubt Apple's display has the same contrast ratio as printed paper, which is also important for readability, but I still think it's likely to give a much nicer reading experience to all those students who are supposed to use iPads as their new textbooks.
Apple posted a clever widget that shows a magnified image of text on the old and new iPads. I pasted an image from it below. Yes, in real life the dots are tiny and it will be hard for some people to see the difference. But eyestrain hinges on little details like this, and as a longtime publishing guy, I can tell you that resolution matters.
On most other hardware specs, the iPad is very good but not overwhelming. Gizmodo has a good comparison here. It shows that the upcoming Asus Transformer matches up pretty well on a lot of the specs, although it's a bit pricier and has less powerful batteries. You could be forgiven for thinking that Android's within striking distance of iPad.
But then there's the software, and this is the second place where I think the new iPad stands out. As a systems vendor, Apple innovates in both hardware and software, so you have to look at both areas to understand the full iPad offering. Apple is innovating very aggressively on the software side. Speech recognition is now being bundled with iPad, and although as I just said I don't think it's ready for writing a long report, Apple has a history of tuning and improving its technologies over time, and I bet we'll see that happen with speech. The keyboard isn't dead, but if Apple makes speech work well, the tablet can more thoroughly displace the PC in a few more use cases (like creating short messages).
Then there are the new iLife tablet apps, which were probably the most compelling part of the whole announcement. I'm very impressed by the way Apple refactored photo editing for touch, and I can't wait to play with it.
Add together the high-res screen, the long-term path for speech, and the new apps, and the new iPad looks like a formidable product.
Hey Google, copy this
Think of it from the perspective of an Android tablet product manager. You don't just have to beat Apple on hardware, but you also have to figure out how to duplicate a rapidly-growing list of Apple-branded software features that are either bundled or sold at ridiculously low prices.
Yes, Google is working to copy any features that Apple adds, but how good is it at integrating UI functionality and crafting exquisite applications? Would you want to bet your product on Google's ability to craft end-user software?
And thanks to Apple's volumes and wickedly controlled supply chain, its prices are low enough that no products other than Amazon's subsidized tablets can get down under them. So as an Android cloner, you're stuck at rough parity on price, and you are increasingly falling behind on integrated software features. It's an ugly life.
And then there's Microsoft
It'll be interesting to see how Microsoft deals with all of this. Windows 8 is an effort to recast Windows for tablets, but will Microsoft be willing to go toe to toe with Apple on app pricing? Undoubtedly not; that would involve giving up most of the Microsoft Office revenue stream. So Microsoft has to walk a difficult line in which it embraces touch tablet functionality, but attempts to convince people that they still need to pay big bucks for good old Office. The first try in that direction, Tablet PC, demonstrated that you can't just cut the keyboard off a PC and call it a tablet. Windows 8 is much more tablet-centric, but if it makes people feel like they're buying a tablet, they may start looking for tablet-like pricing in their apps, and Office sales could collapse like a house of cards.
If that happens, we'll all stop talking about the end of the PC era and talk instead about the end of the Microsoft era.
Some places said it was basically a yawner (link), while others bought into the "end of the PC" rhetoric (link) . Some people even warned all developers to stop programming for the keyboard and mouse, even for complex applications like computer-assisted design (link).
My take: I think the announcement was both more and less important than people are saying. Here's why:
This is not the end of the PC era
I'm sure I'll get some push-back from people who disagree, but I think the whole "PC era" meme from Apple is self-serving hype. Of course they want to convince you that the world is shifting away from a market where Apple has less than 10% worldwide share to a market where Apple has well over 50% share. I'd say the same thing if I still worked at Apple. And the iPad is shiny and sexy, while Windows PCs are old and boring, so I want to believe that the PC is dead. It makes me feel all Jetson-y. But think about it rationally for a minute.
First of all, what exactly was the PC era that is now supposedly ending? Was it the years when Windows was the dominant API for software innovation? That ended in the late 1990s with the rise of web apps. Was it the era when PCs outsold smartphones? That ended last year.
To many people, the end of the PC era seems to mean that tablets are starting to replace PCs as thoroughly as PCs replaced minicomputers. Or that the keyboard and mouse are going away. I don't buy it. We've been declaring the PC dead for at least 15 years, but we're still using them today because for certain tasks, PCs are the best way to get work done. It may be unsexy and it may seem old-fashioned, but if you're working on a big spreadsheet a mouse and numeric keypad are incredibly productive. And if you're writing a report, a keyboard is still the easiest way to input text (for now) and edit (for the foreseeable future).
Kind of like a steering wheel and pedals are still the best way to drive a car. I could do that with a multitouch tablet as well (three-finger swipe to the right means turn at the next corner, four fingers down means apply brakes), but sometimes direct control is the best approach.
And yes (comma) I have tried Dragon (pause) Naturally (pause) Speaking (pause) many times (period) (space) And I found that by the tame I went back and fixed all the types it created (comma) I had not saved any time (comma) plus it was difficult to speak in the sort of sentences I wanted to write because you know I kind of speak more casually than I write (period)
My point is not that touch and speech input and tablets are useless. I think they're great, and I've been playing with them for more than a decade. But I'm going to have the most productivity if I can choose the best tools for a particular job, and that means I still need a pointing device and keyboard for some sorts of work.
Now, if Apple were saying that the PC will be less dominant than it was in the past, I'd have no trouble with that. Although we're not seeing the overall death of the PC, we're definitely seeing a narrowing down of it. For tasks like reading or interacting with content, a tablet is far superior to a traditional PC, and if that's all you do with your PC, by all means get rid of it. But PC-like devices (or maybe mice and keyboards that connect to tablets) are going to linger for the sorts of work that they do best.
So if you have a touch-sensitive screen connected to a keyboard and mouse, do you call that hybrid device a PC or a tablet? I don't really care; it's a game of semantics at that point, and semantics are the playground of companies that want to score marketing points. Which brings us right back to Apple and its enormous tablet market share.
(Oh and by the way, the tablet needs a stylus for certain types of work. One of Steve Jobs' strengths was his willingness to revisit his assumptions when he was wrong, and this is one of those cases. I worry that since Jobs died, Apple may now get locked into his religious opposition to the stylus. That would leave Apple vulnerable to a competitor who does the stylus right by tuning the hardware and software to work together.)
What does matter about the new iPad
Two things stand out to me. The first is the screen. Yes it's very pretty, but that's not the point. The Retina display is a very nice feature in a smartphone, but in a tablet it's far more important because tablets get used more for reading long-form text like novels, textbooks, and magazines.
For displaying photos and videos, enormous screen resolution isn't actually all that important; what matters most is color depth. If you have millions of colors, the pixels blend together and most images look real even at 150 dots per inch. But for reading, where you have sharp contrasts between black text and white background, much higher resolution is needed. At 264 pixels per inch, the new iPad's screen is close to the 300 dpi resolution of the original LaserWriters, which most people found an acceptable substitute for printed text, and which drove a revolutionary change in publishing. I doubt Apple's display has the same contrast ratio as printed paper, which is also important for readability, but I still think it's likely to give a much nicer reading experience to all those students who are supposed to use iPads as their new textbooks.
Apple posted a clever widget that shows a magnified image of text on the old and new iPads. I pasted an image from it below. Yes, in real life the dots are tiny and it will be hard for some people to see the difference. But eyestrain hinges on little details like this, and as a longtime publishing guy, I can tell you that resolution matters.
On most other hardware specs, the iPad is very good but not overwhelming. Gizmodo has a good comparison here. It shows that the upcoming Asus Transformer matches up pretty well on a lot of the specs, although it's a bit pricier and has less powerful batteries. You could be forgiven for thinking that Android's within striking distance of iPad.
But then there's the software, and this is the second place where I think the new iPad stands out. As a systems vendor, Apple innovates in both hardware and software, so you have to look at both areas to understand the full iPad offering. Apple is innovating very aggressively on the software side. Speech recognition is now being bundled with iPad, and although as I just said I don't think it's ready for writing a long report, Apple has a history of tuning and improving its technologies over time, and I bet we'll see that happen with speech. The keyboard isn't dead, but if Apple makes speech work well, the tablet can more thoroughly displace the PC in a few more use cases (like creating short messages).
Then there are the new iLife tablet apps, which were probably the most compelling part of the whole announcement. I'm very impressed by the way Apple refactored photo editing for touch, and I can't wait to play with it.
Add together the high-res screen, the long-term path for speech, and the new apps, and the new iPad looks like a formidable product.
Hey Google, copy this
Think of it from the perspective of an Android tablet product manager. You don't just have to beat Apple on hardware, but you also have to figure out how to duplicate a rapidly-growing list of Apple-branded software features that are either bundled or sold at ridiculously low prices.
Yes, Google is working to copy any features that Apple adds, but how good is it at integrating UI functionality and crafting exquisite applications? Would you want to bet your product on Google's ability to craft end-user software?
And thanks to Apple's volumes and wickedly controlled supply chain, its prices are low enough that no products other than Amazon's subsidized tablets can get down under them. So as an Android cloner, you're stuck at rough parity on price, and you are increasingly falling behind on integrated software features. It's an ugly life.
And then there's Microsoft
It'll be interesting to see how Microsoft deals with all of this. Windows 8 is an effort to recast Windows for tablets, but will Microsoft be willing to go toe to toe with Apple on app pricing? Undoubtedly not; that would involve giving up most of the Microsoft Office revenue stream. So Microsoft has to walk a difficult line in which it embraces touch tablet functionality, but attempts to convince people that they still need to pay big bucks for good old Office. The first try in that direction, Tablet PC, demonstrated that you can't just cut the keyboard off a PC and call it a tablet. Windows 8 is much more tablet-centric, but if it makes people feel like they're buying a tablet, they may start looking for tablet-like pricing in their apps, and Office sales could collapse like a house of cards.
If that happens, we'll all stop talking about the end of the PC era and talk instead about the end of the Microsoft era.
Subscribe to:
Posts (Atom)